I use emacs for most online text editing, for PHP and javascript files especially. "PHP Abbrev" seems to be the mode for PHP files?
Lately I've been getting this error a lot within emacs, for a specific file:
"Error in syntax_table logic for to-the-end intervals"
The file is upwards of 5000 lines of PHP functions only, with no syntax errors, and runs well.
Yet sometimes (not always) I get that error, which seems to imply some sort of balancing issue. The worst part is that it prevents me from typing things like { } brackets, and I can't even write the code I need. Sometimes I need to code within comment brackets for it to allow it, then remove them at the end.
Is there any way to bypass this somehow, or detect if there is actually a balancing issue somewhere?
Related
I am required to print huge amounts of data ( in the order of a few 100 MBs) on the console. Using println for this is failing miserably on IntelliJ.
Is there any alternative like console.log which can handle and display this data without lagging and slowing down?
Thanks in advance!
You can buffer, and perhaps bypass character encoding. It's also worth looking at the IntelliJ settings, particularly if you don't see this problem when running from the commandline - perhaps IntelliJ is offering some functionality in its console (e.g. highlight errors, link stack traces to line numbers) that involves scanning every line. You might also worry about word wrapping in your console
(That said, I'm not sure how you expect to understand anything from 100MB of printing - if it's something you need to look at an overview of to "see the pattern", try making code see the pattern the same way you do)
When running emacs calc, typing a prefix key, say 'm', followed by '?' is supposed to show all mode-related commands in the minibuffer as a kind of quick help facility.
For several years I have noticed that this quit working for me. When I hit the '?' the minibuffer flashes the help for a small fraction of a second, then goes blank. I can sometimes see parts of the help text rendered but ususally it blanks too fast to see it.
This does not happen when I run emacs -Q to skip my init file, so it is something in the init file that is the cuplprit.
My init file is quite large. I would like to put something like '(exit)' in different places in my init file to stop processing the init file and see if I can pin down what is causing the problem.
(1) What is the right way to do this?
(2) Anybody else see this problem with the minibuffer in calc?
Good question. The answer is simple: recursively bisect your init file.
Do that by commenting out 1/2 of it, then 3/4, then 7/8,... This is a binary search, and it is very quick, even though it might not seem that way at first. It is systematic, and essentially blind (thoughtless).
To comment out a block of text, use command comment-region. To uncomment a block of text, use C-u with the same command.
Trust me - in no time at all, you will have identified the culprit code, no matter how big your init file is. And if you load other libraries from your init file, and doing the exercise above shows that the culprit code is in one of those libraries, then do the same thing with (a copy of) that library code: recursively bisect it.
After several hours of trying to narrow down the problem, I found the culprit.
When key-chord-mode is set on in calc, the key help facility displays the symptoms I mentioned above.
Would like to keep key-chord enabled globally and disable it in calc-mode, but turning it off in the calc-mode-hook turns it off for all modes. Any ideas?
Anyway, I am closer to figuring out this long-term irritant.
I have installed the persp-mode and workspaces packages from the elpa repository. persp-mode depends on workspaces.
I was unable to get persp-mode working until the workspace.elc file was deleted. I have made a backup of this file for troubleshooting.
What could have been the cause of error?
How can I debug this problem systematically?
Without you giving us the error message it's hard to know what caused this, but generally the easiest way to debug compilation issues is to restart Emacs (so you have a fresh image), go back to the source file and recompile it with M-x emacs-lisp-byte-compile-and-load. This will show you any errors or warnings that occur when the file is compiled. Look for the following:
undefined variables and functions, which often indicate
features that have not been required by the package
simple typing errors
unexpected end of input errors, which indicate unbalanced parens
general usage errors, such as
function calls with incorrect argument counts
macro expansion errors
These sorts of issues are usually pretty easy to fix. Remember, you can always redefine the package's functions and vars yourself if they are broken.
Every time when I finish running a matlab code collection on command line, when I exit matlab, the standard output just gets messed. I can still use the terminal window, but whatever I typed won't show up on the screen, leaving me either type with my eyes blind, or open up a new terminal and excessively cd to the old place.
This happens every single time when I use make to run a matlab collection, and since I'm working a lot on this, it turns out to be very annoying. Does anyone know what's the problem here and how should I fix it?
As was pointed out in the comments, the makescript is probably dumping "bad" characters to the terminal. You could prevent this (but possibly lose useful information) by redirecting the output - instead of sending it to the terminal window, you can send it to a file, or even /dev/null ("the great bit bucket in the sky").
The underlying problem, however, is that your makefile is even sending these characters to the terminal in the first place. I would recommend that you pipe the output to a file with something like make > myDump.txt, then examine the resulting file to see what is going on, and where in your makefile the problem is created. It is possible that you will still be getting some output when you do this - that's because by default > redirects stdout only, and not stderr - a second output stream used for error messages. You can redirect both to a file with make 2>&1 myDump.txt.
You have already seen the recommendation to use stty sane to restore the status of the terminal - I am repeating it here in case someone only looks at answers, and not at comments; but I don't take credit for it :-).
It seems this forum is more alive than mailing list : http://sourceforge.net/mailarchive/forum.php?forum_name=cedet-semantic.
I would like repost my quest from a week ago from there:
First hi to all who contribute to this great package as CEDET :D .
Without much hussle I am able to get working most of the CEDET futures, but when it comes to senator / semantic things get more tought :\ .
Parsing local files are fine.
I don't use EDE not to get things more complicated.
I use the 1.0.6 git trunk version, for compability with ECB.
First is the rumble about the emacs core / cedet git-trunk hussle. How do I check that current installation is running the latter ? ( I have done some .emacs modificaitons see below) .
I generally cannot get the proper autocomplete working for external libs - in this case the OGRE3D project, which all are in the /usr/include/OGRE. I suppose I have added to 'search path' include properly, semantic-describe-c-env. sees them added properly.
2.a What are the basic commands to the semantic parser ? , that is I need to force it to parse the desired includes.
Once I saw semantic parsing the OGRE files in the 'idle time'. Still the autocomplete does not work ( OGRE:RAY is not recongized as a type).
senator-completition-menu-pop gives some non-matching 'c**p'
2.b I know there are customize-group options for semantic, tough their description say little to me.
From the other post:
"Yes, there is a setup cost. You can use semanticdb.sh to pre-parse your
code, but if you never open every file, you might end up with Emacs
having such a huge data structure it gets larger that your machine can
handle. If your project is small, this shouldn't be a problem."
Well this might be, if that would parse OGRE.
here's my .emacs:
.emacs at pastebin.com
Here's what I got on the mailing list, hope that it would help someone , thaks to Eric Ludlam :D :
======================
1. First is the rumble about the emacs core / cedet git-trunk hussle. How do I check that current installation is running the latter ? ( I have done some .emacs modificaitons see below) .
After emacs start, use:
M-x cedet-version RET
and look for the 1.1 version from CEDET/bzr.
I just tried this and noticed not everything has the right version
number. Interesting. I'll have to look into that.
Anyway, the next thing to try is:
M-x locate-library RET cedet RET
and make sure it points where you think it should.
2. I generally cannot get the proper autocomplete working for external libs - in this case the OGRE3D project, which all are in the /usr/include/OGRE. I suppose I have added to 'search path' include properly, semantic-describe-c-env. sees them added properly.
If you enable global-semantic-decoration-mode you can right-click on
header files, and it will give you some options, such as showing where
it things the header is, and showing if it has been parsed yet or not.
2.a What are the basic commands to the semantic parser ? , that is I need to force it to parse the desired includes.
You can use the include menu to force a header to be parsed, or visit
said include. If it can't find it, you can add OGRE to your path from
there too.
If you vist your header, you can use the senator menu to force a file to
reparse, or use:
C-u M-x bovinate RET
to do it.
Once I saw semantic parsing the OGRE files in the 'idle time'. Still the autocomplete does not work ( OGRE:RAY is not recongized as a type). senator-completition-menu-pop gives some non-matching 'c**p'
Autocomplete can fail for many reasons. The best way to find out why is:
M-x semantic-analyze-debug-assist RET
at a place you want to do completion. It will tell you about your
header files, symbols, and the like. It could be your preprocessor
symbols need some setup.
For large complex library headers, sometimes it is just a matter of
having the right pre-processor symbols setup in Semantic so that the
right bits of the headers get parsed for symbols. You'd have to visit a
header where a symbol you want to complete is, and see if it was parsed.
Using:
M-x boviante RET
will dump the symbol table.
2.b I know there are customize-group options for semantic, tough their description say little to me.
From the other post:
"Yes, there is a setup cost. You can use semanticdb.sh to pre-parse your code, but if you never open *every* file, you might end up with Emacs having such a huge data structure it gets larger that your machine can handle. If your project is small, this shouldn't be a problem." Well this might be, if that would parse OGRE.
I doubt parsing the includes is the problem here. I think there is just
something new in the ogre headers we'll have to deal with.
Eric
===================================