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.
Related
I've Emacs setup for Verilog, SystemVerilog and UVM.
I use auto-complete, solarize theme and verilog-mode as add-ons.
I need to work on C once in a while, however with C Emacs feels very laggy (takes a while for auto-complete suggestions) and it creates bunch of 0 byte files in my working directory (with names containing symbols -- not letters).
I'm not sure about the cause or how to debug and solve the issue. I would appreciate if someone can help me with finding and solving this issue.
[EDIT]: I understand this can be lacking in information, however right now I'm not sure what type of information I should be providing, I will provide information as required
[EDIT2]:
I've commented following portion of init file and my c editing is working well, What part of loading auto-complete can cause these?
The problems I was facing:
1. Creating random symbol files with 0 bytes of size in working directory (name would look like ?/??UR...)
2. Laggy: takes a while for character to show up when typed
;; This section is required to enable autocomplete and verilog dictionary
;;(add-to-list 'load-path "/home/user/.emacs.d/")
;;(require 'auto-complete-config)
;;(add-to-list 'ac-dictionary-directories "/home/user/.emacs.d//ac-dict")
;;(ac-config-default)
;;ac-modes - mojor modes ac can run on
;;(add-to-list 'ac-modes 'verilog-mode 'c-mode)
;;toggle auto complete in all buffers
;;(global-auto-complete-mode t)
I understand this can be lacking in information, however right now I'm not sure what type of information I should be providing, I will provide information as required
That's the right attitude, and yes, you sensed correctly that the problem description is currently too broad for people to be able to help (unless you are lucky and find someone who recognizes the same combination of setups etc.).
The first step is to isolate the cause of the problem, at least to one (instead of 3) feature that you are using. IOW, break down your "setup for Verilog, SystemVerilog and UVM" which uses "auto-complete, solarize theme and verilog-mode as add-ons", so that you can report that the problem is only in using, say, auto-complete. Or is only in the combination of, say, theme solarize with verilog-mode.
IOW, at the highest level this is no different from any other debugging scenario.
As it stands now, you are, in effect, telling us that you have this big sack of stuff and you want someone to guess what is going on.
To narrow the problem, recursively bisect your init file, commenting out bigger and bigger chunks, until you know what part(s) of it are really causing the problem. Comment out 1/2, then 3/4, then 7/8,... You can use command comment-region to comment or (with prefix arg C-u) uncommment the selected text.
Once you have a better idea of what is causing the problem, report back here with the refined problem statement and the additional info you've learned.
At that point you will also want to specify what you mean by this or that being "laggy". You will hopefully be able to give others a recipe to reproduce the effect you see, and you will be able to describe better what you expected to see, but didn't.
I have an org-mode file that I'm trying to export to a Beamer LaTeX PDF through XeTeX. It was working fine last night on this machine, and just as well on another machine on which I edited it afterward. Both are running org-mode 8, Emacs 24, same export process (3 runs of XeLaTeX)
When I synced back to this machine and tried to export again, I got the error Wrong block type at a headline named "". I checked all my headlines and gave them all names, but still got the same result.
Thanks to the wonders of indexed searchable FLOSS code, I immediately found the snippet online:
(env-format
(cond ((member environment '("column" "columns")) nil)
((assoc environment
(append org-beamer-environments-extra
org-beamer-environments-default)))
(t (user-error "Wrong block type at a headline named \"%s\""
raw-title))))
I'm not really solid on elisp at all, though, and I don't know most of what's going on here. From this snippet, what would I do to start debugging? (I realize I can start the emacs debugger, but it's not a PKE meter, I can't just wave it around.)
IMHE the best way to figure out what's wrong when you've found the relevant snippet of code is to use Edebug.
You should read the documentation to learn more about it, but basically here is my procedure:
identify the part of the code that crashes
instrument the code with Edebug (C-uC-M-x)
re-execute the code and go step by step to figure out what's going on (n)
If the problem is in another function, jump to it GOTO 2.
Iterate until you've understood the code and find a way to fix it.
Posting this answer just so that the specific solution to the particular problem the error was flagging is understood.
Apparently the version of Beamer I have on the other machine has a "normal" Beamer environment that specifies an otherwise blank, unformatted block. This is not present in this machine's install, or at least org/XeLaTeX don't know about it.
My steps were:
Search for all unnamed headings
Name each of them uniquely
Reproduce the error with the identifying string
Check the block type property against the available type list given in org-beamer-mode
Remove the offending type and replace it with another one
This is great and all, but I don't think it's the "best answer" because it involves no actual understanding of what the emacs interpreter was trying to tell me. If I didn't have a good idea of what was going on generally with the TeX, there's no way it would have worked. Dunno if this technique would impress anybody at an interview ;)
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
===================================
There's a small nuance that's been bugging me for a while, namely that I frequently type #inclued instead of #include. If it wasn't obvious, I program a lot of C and C++. That typo has wrecked countless builds and consumed time that would have been better spent drinking coffee or surfing stackoverflow. Surely emacs can be helpful and rectify my mistakes as I type (in cc-mode only, of course). But how?
Googling and searching stackoverflow didn't provide any answers.
You could use this in abbrev-mode: After you entered #inclued, do C-x a i g include RET, and from then on, every time you type #inclued, it will be changed to #include automatically. If you want that abbrev to be local to a mode, use C-x a i l instead of C-x a i g. Also, you can edit your abbrevs with M-x edit-abbrevs.
A nicier and more global solution than abbrevs (because you can't predict all the typos you'll make) is to use flymake (which comes with emacs distribution).
http://flymake.sourceforge.net/
Flymake checks your source code behind the scene while you're still typing your code into the buffer. It highlights what's wrong with your code (that is : what gcc tells is wrong).
Running gcc in the background does not use more CPU than your antivirus bloatware. Moreover, if you have 2 or more cores, gcc can take advantage of parallelization. It only checks the syntax, not compiling anything.
if you're interested in something a bit different, you could write all your little piece into snippets, using the YAsnippet package, then you could type something like #in, hit TAB, and it will expand into... whatever you want.
Sounds like flymake is exactly what your after. It runs a compiler in the background, and will hightlight errors, as you type.
I was going to suggest that this could be a slightly odd application for flyspell, but danlei's answer looks better.
I'm writing a text with Latex in English but written my comments in Finnish. When I'm running the spell checking with ispell, I got to run through all the comments. Is there a handy way to skip the comments with the ispell? If that could be done with emacs, that would be double handy =)
One way would be to run the ispell within console and process the input with sed, for example, but I'd like to have my changes straight on the file...
(setq ispell-check-comments nil)
You'd have to dig in the code a bit, but when you spell-check a file, it's running the detex tool to strip out the TeX code. You should be able to modify the pipeline to have a sed or perl script strip the comment lines.
I kind of vaguely think AuC-TeX makes this configurable, but 30 seconds looking didn't reveal it.
Adding a modern answer to this old question, because I also had the problem:
Just use aspell, which does this out of the box.