I must be in the habit of leaving the mini-buffer in the middle of a command. From there I will change buffers and continue working. Later (sometimes much later) I'll notice that I had a command dangling incomplete in the mini-buffer. If I go to cancel it with a C-g, Emacs will often swap buffers in my open windows to an earlier state.
I suppose this may be a feature, but in my flow of work I find it rather annoying. Is there a way to stop this behavior or prevent it from happening, such as a warning that There is an incomplete command?
I think that the answer to another question will help you solve this. It can be an annoying behavior, but the solution limits some of the flexibility found in Emacs.
The answer is: How can I prevent the mini-buffer from displaying previous commands in Emacs? (I call it stop-using-minibuffer).
Related
I'm using Proof General in Emacs on Aquamacs and every time I write a period (".") everything is executed (up to that period). It seems like an electric behavior but it's not. All other keys behave normally.
I know that this is some mode that started when I accidentally used some keybinding. If I restart the session the effect will stop, but I would like to know the keybinding to make it stop (or to make it start).
Do you know what this mode is called? I can't even find it online.
In general, if you're stuck in a minor mode that you don't know the name of, you can run:
M-x describe-mode
This will list all currently active major and minor modes, with a description of each. From this, you should be able to figure out which one you need to deactivate.
When I use emacs, I often meet some errors in my code.
When there are some errors in my code, emacs ask me whether I want to "abort" or "terminate-thread".
I want to know what the difference is between "abort" and "terminate-thread" in emacs.
Which one should I choose that will be better?
I don't think this question comes from Emacs. So please give us more information (OS in which you run Emacs, which processes you might be running within Emacs, what kind of error happens, where is the actual question displayed (within Emacs's minibuffer, or some popup dialog), ...
Are you using SLIME?
In that case, "abort" will just stop your program, whereas "terminate-thread" will also kill the Lisp thread that SLIME is talking to.
There's an external library I'm working with that frequently pegs my CPU. I'd like to help the author fix it (as I really like the library), but I don't know how to debug the crash properly.
Any tips for debugging Emacs lisp? Bear in mind when it crashes Emacs doesn't work anymore and I have to kill it (so solutions within Emacs itself might not be helpful).
Edit: I should clarify that it is byte-compiled, and this issue doesn't always happen for others, so it may be specific to my architecture/init files. It is definitely related to this library though.
First, always debug the uncompiled version of a Emacs-Lisp program, unless you're convinced the problem is introduced by the byte-compiler.
Second, if the code is hanging Emacs then the code is probably in an infinite loop with inhibit-quit bound non-nil. So the first thing to do is go through the source for the library and change all inhibit-quit references to something else so that C-g will work to stop the looping. After that, load up the library, set debug-on-quit to t and you should get a nice debug trace when you press C-g that shows you where the code is looping. From there, debugging the problem should be as straightforward as debugging any other infinite loop.
I'm not sure how to comprehensively accomplish this.
Currently I build my own bzr Emacs on Windows, so I can see that `display-buffer' now takes a SPECIFIERS option, which could be interesting, but I couldn't find concrete examples of how to use it.
But this problem really has to be solved before display-buffer is called.
For example a Help window previously was visiting Buffer-A, but I've visited Buffer-A in another window while reading the help. Now when I quit the Help window, Buffer-A appears there as well. I want some other useful buffer to appear there.
I have some experimental code that appears to work here.
I emphasize experimental. This could melt your Emacs.
I'd appreciate it if you could contact me on github or here to let me know your experiences with this.
Emacs 24 is not yet released. They have changed the buffer-display/window behavior and Lisp interfaces several times over the release's development period. The current status of the release is pretest, so development is supposedly stopped, except for bug fixes.
However, ongoing emacs-devel#gnu.org discussions show that things are still in flux wrt buffer display and windows.
Your best bet is to check the latest doc and code (which might not correspond exactly, at this point).
I find that when I copy or delete large files with Emacs from dired, (i.e. S-c), Emacs will lock up until the operation is complete. To work-around this I fire an asynchronous shell command 'cp/mv/rm ' so that I can do other things while I'm waiting. My question is that, has anyone else encountered this issue? And if so have you managed to work around it? I'm using the latest stable GNU Emacs 23.2.
Yes, I got the same behavior. I think the reason is that Emacs is not multi-threaded. You can find more information here.
In my opinion it's one of the major drawbacks of Emacs.