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.
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.
I'm an Emacs user trying to learn a software tool that is best run from a terminal. The default set-up to get the most out of that tool is to use xterm for interaction and call Vim for editing. One could simply replace Vim with Emacs in this setup, but then one would spend most of the time working outside of Emacs in an Xterm.
I figured out there is (Multi)Term-mode in Emacs, but it is really hard to find out about its pros and cons. So I have the following questions:
[Without X11]: Why or when would anybody use Emacs (Mutli)Term instead of Console & TMUX (or GNU Screen)?
[With X11] How does Emacs (Multi)Term compare to Xterm?
Obviously speed is one criteria for comparison, but I'm sure there are other.
You'd use Emacs term over tmux/screen if you're more familiar with Emacs and already use it for many other things and/or if you spend more time in Emacs than in the terminal.
Emacs's Term is much less sophisticated and much less reliable than xterm. But it works within Emacs so if you live in Emacs, it might be a good option.
Note that you may also prefer to use Emacs's M-x shell functionality, which gives you a command line without giving you an actual terminal emulator. That means that the commands are edited in Emacs before being sent to the underlying command-line program, so all the usual Emacs editing can be used there (and the history manipulation as well as command completion is performed by Emacs as well, which can be great, or can be disappointing (e.g. if the completion needs info which Emacs does not have)).
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 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).
I'm not sure if this is possible, but does anyone know if I can pipe ESS commands (i.e. evaluate region) to a R process running outside of Emacs? The Emacs terminal hangs up a bit (more often than Apple's terminal) and I'd like to just ditch it, while still using ESS commands. Currently I am doing the less efficient copy and paste technique :-)
Vince
Why not just kill the underlying R process, start a new one and continue the session in the same ESS buffer?
This doesn't answer your specific question and my experience is on Windows, but assuming it's challenging in ESS, I just mention:
There are other IDE's which have no trouble doing this (e.g. Tinn-R, StatET). In particular, for one supported on multiple operating systems, have a look at the StatET plugin for Eclipse. One very nice feature of Eclipse is that not only can you run the commands on a console outside the IDE, but you can also run multiple console sessions at the same time. This allows you to easily compare results side by side.
Needless to say, that's irrelevant if you're comfortable using ESS.