I recently felt the need to work with Spacemacs for my erlang/elixir projects.
(was coding Erlang on eclipse).
Now i'm feeling a bit more comfortable with Spacemacs, i have a question regarding how to deal with processes.
I made a mistake on my code and had an infinite loop.
I killed it on console but i was wondering how to do the same thing within spacemacs.
I've found that SPC a p gave me the possibility to list all the running processes.
Can please someone explain me (i'm a complete beginner on spacemacs/emacs) if it is possible to kill a running process within this menu ?
Regards
Pierre
M-x proced
Choose your line and then k
In Spacemacs, SPC a p, which runs the command list-processes, opens a buffer showing only those processes started by Spacemacs.
The list process buffer is evilified, so j and k navigate the list of processes,
d in the list process buffer will immediately delete the process under the cursor (no prompt to confirm is given, so ensure its what you want to do).
q will quit the process list and close the buffer.
Note: SPC a P will list all operating system processes, not just those spawned by Spacemacs.
Reference: https://practicalli.github.io/spacemacs/install-spacemacs/troubleshooting.html
Related
When using typeclasses, Coq sometimes diverges. When this happens under Proof General, Emacs also hangs.
The best way I know to recover is to interrupt emacs (C-g) and restart Coq (C-c C-x). But, instead of just killing the Coq process, this puts me in a mode where Emacs is again hung, displaying "Retracting buffer..." for a quite long time (sometimes so long that I give up and just start a whole new emacs!).
Why?
Is there a better way? (And: Is there an easy first step for viewing what is diverging in the first place when this happens?)
If emacs is hung on anything other than garbage collection, you can generally interrupt it with C-g. If C-c C-x / C-c C-c don't work, you can kill the coqtop process from process manager / from the command line with pkill coqtop.
This happens because coqtop has some loops where it does not check for interrupt, or does not check often enough, and so it does not catch the interrupt from PG in a timely manner.
Additionally, as mentioned in other answers, Set Typeclasses Debug will give you a very verbose log of typeclass resolution in the *response* and *coq* buffers.
I don't know if this actually does anything, but sometimes I find that Proof General interrupts Coq if I press C-c C-c a few times.
As for your second question, you can add Set Typeclasses Debug. to your script before invoking the problematic line. Then Coq will print a trace of its instance search in the *response* buffer in Emacs. If your script is looping, make sure you hit C-c C-c right after triggering the loop, as the trace can get very long quite fast
For the last bit, I reminded myself of
Set Typeclasses Debug.
Strange: I'm not actually sure any more whether emacs is stuck at the end or whether it's a display bug: it seems that if I switch to another screen and then switch back I find the coq exited message that I expect, right away.
In emacsclient, is there a way to open a file from the command line such that its buffer will remain open on the server after I close the client?
Alternatively, is there a command I can run from in a client to tell it to effectively detach from a buffer, so that the buffer does not get killed when the client exits?
Normally when closing emacsclient either with C-x C-c or C-x #, the buffer(s) associated with that client get killed, which is usually convenient behavior, but sometimes I would like for buffers to stay alive after closing. So far the only way I have found to accomplish this is to run the client without specifying any files, then visit them with C-x C-f, but I'm wondering if there's a better way to do this.
You should be able to do this by using the -n option. That means that it won't wait for you to "finish" the buffer and it'll just stay in the buffer list. I use this with emacsclient myself.
So, one option is to use emacsclient's eval command line option to run a lisp command to find the file you want.
emacsclient -c -e '(find-file "my_file")'
Obviously this is a lot more to type than the command sequence emacsclient -c, C-x C-f, my_file, but it could pretty easily be wrapped in a script that takes an extra argument to tell it whether to just choose the file or use find-file.
Someone more well versed in elisp than I could probably just add the option directly into emacs.
According the info manual, if you never want to kill emacsclient buffers, when you're done with them, you can customise the server-kill-new-buffers variable (more information at C-h v server-kill-new-buffers).
For you use-case, depending on how often you want the buffers killed or not, you could set the above variable to nil and then manually kill the buffers that you do want killed.
I am developing project in clojure using emacs cider under windows. And sometimes I have a problem that after accidently forgotten println function or on printing contents of big file Emacs stops responding (cursor and all key combinations doesn't work) and retire into oneself for processing that information to show it in repl. The only way to continue I know is to close program and open project files from scratch. And it is so simple to get in this trap.
Are there any other better solutions or configuration restrictions?
Though this suggestion will not solve your problem completely, it can help you a little.
First, set *print-length* to some value to limit the number of items of each collection to be printed.
(set! *print-length* 10)
And use cider-connect instead of cider-jack-in. You should run lein repl in a separate console window, then run cider-connect to connect to the repl. Then you can evaluate some expressions in the console window.
It would be good if there's an option to limit the contents to be printed by number of characters, however, I couldn't find it.
In certain kinds of code it's relatively easy to cause an infinite loop without blowing the stack. When testing code of this nature using clojure-test, is there a way to abort the current running tests without restarting the swank server?
Currently my workflow has involved
$ lein swank
Connect to swank with emacs using slime-connect, and switch to the the tests, execute with C-c C-,, tests run until infinite loop, then just return but one cpu is still churning away on the test. The only way to stop this I have found is to restart lein swank, but it seems like this would be a relatively common problem? Anyone have a better solution?
Yes, it is a common problem for programmers to write infinite loops in development :). And the answer is very simple. It's called "Interrupt Command" and it is C-c C-b
Leiningen has nothing to do with this. This is SLIME/Swank/Clojure. When you evaluate code in Emacs you are spawning a new thread within Clojure. SLIME keeps reference to those threads and shows you how many are running in the Emacs modeline. If you're in a graphical environment you can click the modeline where it indicates your namespace and see lots of options. One option is "Interrupt Command"
Eval (while true) and C-c C-b to get a dialog showing a java.lang.ThreadDeath error with probably just one option. You can type 0 or q to quit that thread, kill that error message buffer and return focus to your previous buffer.
As per this old discussion, adding (use 'clojure.contrib.repl-utils)) and (add-break-thread!) to user.clj should enable you to press C-c C-c for passing SIGINT to the long running evaluation/processe.
if all else fails.. alt-x slime-quit-lisp and restart the REPL. try Psyllo's answer first of course.
I often have several comint buffers open at once, for example I'll have a SQLi buffer open to a database and a set of shell buffers open in various places. Sometimes, for no reason I can detect, all of these buffers start to share a common buffer command history, such that M-p will pull up my last SQL command in a shell-mode buffer, and so on.
How can I fix this? What on earth is causing it?
Have you exited from any of the shells or SQL sessions? Long time since I used emacs but I seem to remember when a shell terminated the commands would be part of a 'global-command-history-list'.
note - A shell can quit, but the buffer will still be there in emacs.
It sounds like there is something else going on in your system that you are not aware of. One possibility may be something in your .emacs is mixing between buffers without your knowledge. Another possibility is that you are inadvertently moving data through your copy-and-paste system.