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.
Related
I used to be confident of returning to buffer from mini-buffer by just pressing C-g once, until I learned there is a "recursive-edit-mode" inside Emacs Here, which seems to make cancellation action inconsistent. Therefore, I am reading the entire section in hope of finding a more consistent / stateless command to return to mini-buffer.
However, I encountered below problems when following and trying to replicate what the manual says:
Entering Recursive-edit-mode: After "M-x query-replace RET C-r" (in Fundamental-mode), I could not replicate "a pair of square brackets" in mode-line. However, now I DO have to press C-g TWICE to return back to buffer.
Question: Does recursive-edit-mode still have square brackets now? (I am using ver 24.3)
Quitting: The manual directs me to the Quitting section for quitting command. It says Aborting with C-] (abort-recursive-edit) is used to get out of a recursive editing level and cancel the command which invoked it. So I tried it out within "M-x query-replace RET C-r", hoping one C-] will get me out from minibuffer to buffer, but it still takes 2 shots to do that.
Question: Is this normal? If yes, any other command to guarantee command abortion and return to buffer with 1 execution?
Just want to brush frequently used command such as C-g. If made consistent, it may help avoid inputs being eaten (sometimes unnoticed) by the minibuffer due to trapped inside recursive-edit-mode.
Visually confirming point each time inside the buffer makes keyboard input an closed-loop feedback process and thus consumes more attention, though.
You definitely will see square brackets in the mode line for a recursive edit -- but not for a recursive minibuffer.
C-g does act consistently, but it does different things in different contexts (always the same thing for a given context, however). That can be confusing. It can take some getting used to - a bit like it takes getting used to the various behaviors of C-g during Isearch, depending on the current search state.
If you use recursive edits or recursive minibuffers then you need to pay attention to clues wrt the current state/context. Again, this is like learning Isearch. minibuffer-depth-indicate-mode is a must, to provide feedback about what state you are in.
FWIW, beyond minibuffer-depth-indicate-mode, I use a standalone minibuffer frame, and with each recursive edit or recursive minibuffer the background hue is changed slightly, to better indicate the level etc. (The background color changes slightly also for (a) active minibuffer and (b) Isearch. I use library oneonone.el for these things.)
If you don't use a standalone minibuffer frame then you might consider highlighting the square brackets or something else in the mode line, to help you tell where you are at.
C-r during query-replace is a good example of when a recursive edit can be useful. There are a few others. But generally I do not make much use of recursive edits, FWIW. (I do, however, use recursive minibuffers a lot, because I use keys bound in minibuffer maps that do invoke commands that themselves might prompt for input etc.)
Wrt your question about query-replace with C-r: There is no minibuffer involved at all, here. And C-] after C-r does end not only the recursive edit but also the query-replace (whereas C-M-c ends the recursive edit and returns to the query-replace.
FWIW - In Icicles interactions, you might find yourself within any number of recursive minibuffers. (For example, you might use progressive completion to successively narrow the set of completion candidates, and each narrowing opens a recursive minibuffer.)
C-g always aborts the current command, or if there is none then the current minibuffer, and C-] always aborts the current minibuffer. Repeating C-g (or C-]) pops back up the minibuffer chain, a level at a time. But (in Icicles) you can use C-M-S-t (aka C-M-T) to pop directly back to the top level (exit all minibuffers).
Similarly, answering a minibuffer prompt (e.g. hitting RET or using mouse-2 on a candidate in *Completions*) exits the current minibuffer, popping up a level (to the parent minibuffer or to the top level if there is none). (In Icicles RET can optionally put you back at top level.)
I usually encounter situation when I enter minibuffer command such as open file or change buffer and instead of completing it in a minibuffer, I start doing something else, usually editing the buffer. I would like that minibuffer simply forget the command if it was not completed after some period of inactivity in a minibuffer. Is it possible?
If it would be possible to make the minibuffer simply flush itself after losing focus it would be great too. Now frequently I get the queue of minibuffer commands waiting for me and it is annoying as hell, since when I C-g them, emacs changes the buffers in the frames.
I wouldn't really advise doing anything of the sort, but would suggest instead that you provide a visual clue to yourself when the minibuffer is active. But since you asked for it...
You can put a function to exit the minibuffer on a suitable hook or in a timer. The function could check the value of (active-minibuffer-window) and call, say, (top-level) to return to the top level whenever it is nil. (Function abort-recursive-edit will exit the current minibuffer, but that can return to a parent (shallower) minibuffer, not necessarily `top-level'.
What hook or timer to use? You could use `post-command-hook', which is run after each command (e.g., each key press). That is perhaps overkill, but it won't miss a chance. There is perhaps another, more pertinent hook; dunno.
You could use an idle timer, which kicks in only after Emacs has been idle for a specified time. Or you could use a regular timer, just checking periodically. A timer could be started on minibuffer-setup-hook and then canceled on minibuffer-exit-hook.
I am using emacs and the auto-newline feature is not working as expected. I have a pretty large number of customizations done to my emacs. So it would be no wonder if one of the other customizations is not what auto-line is expecting. I would like to know if there is a way to know the list of commands (list of emacs commands) executed by emacs at a particular point, for e.g. when ctrl-s ctrl-c or in my case when auto-line feature is called.
edit : I think you have misunderstood the question. I would like to know what command emacs calls 'internally'.
I believe view-lossage is what you're looking for -- M-x view-lossage, or C-h l.
If you want to know what a keystroke is bound to, consider using describe-key, which is usually bound to C-h k.
Basically at this point, you need to bite the bullet and learn some Emacs-lisp. The debugger is what you are looking for to dig further into your problem (I use edebug). It's not just about seeing what functions get called, you also need to see the values of the relevant variables when those functions are called.
If you feel you're not up to it, then you can bi-sect your init file until you find the culprit, but at that point you still need some Emacs-lisp to investigate further.
To add to what #event_jr said --
What you seem to be asking is the history of the functions called by the command you last invoked. (You speak of Emacs "internal commands", but it seems you just mean functions.)
To get that history for any given command you invoke (e.g., by a key), use M-x debug-on-entry and then enter the command name. The next time you use that command, you can walk through its execution in the Emacs debugger (hit d to step, c to continue past a step).
I installed ClojureBox and the REPL is not working.
If I type (+ 1 2) into the *slime-repl clojure* buffer and press enter, the expression text becomes bold as if it has been evaluated, but there is no result of the evaluation printed on the screen.
Can anyone help me figure out why my REPL is not printing the evaluation results?
Thanks.
Try looking in *inferior-lisp* and failing that all other buffers.
The binding of clojure's *out* plus emacs slime-swank based capture and redirection of output streams can occasionally make it seem like emacs is swallowing output. (This can get really confusing when output comes from multiple threads - definitely one of the few warts of developing clojure with the slime-swank environment.)
Have you ever tried emacs before using clojurebox? Any left behind .emacs configuration or library paths etc. can interact badly with clojurebox which, in my experience, assumes it is the only installation of emacs going onto a clean system.
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.