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.
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.
I know how to enter recursive edit mode when query-replace (M-%), but sometimes I really don't want to modify the code instead I'm just in searching. Such as when I was reading code, and from one point I saw a function call, then I want to jump to the declaration of the fucntion (C-r Enter PageList::Init), when I have read the declaration I want to jump back to the calling of the function.
How to enter recursive edit mode when searching (not only when query-replace)?
You can open a recursive edit while you are searching, if you use Isearch+. Then, C-x o is bound during Isearch to command isearchp-open-recursive-edit:
Invoke the editor command loop recursively, during Isearch.
Use C-M-c to end the recursive edit and resume searching from there.
Or use abort-recursive-edit to exit the recursive edit and cancel the previous search.
If you do not want to use Isearch+ then this is all you need:
(defun isearchp-open-recursive-edit ()
"Invoke the editor command loop recursively, during Isearch.
Use `\\[exit-recursive-edit]' to end the recursive edit and resume searching from there.
Or use `abort-recursive-edit' to exit the recursive edit and cancel the previous search."
(interactive)
(with-isearch-suspended (recursive-edit))))
(define-key isearch-mode-map "\C-xo" 'isearchp-open-recursive-edit)
If you are asking about recursive editing generally, and not just during search, then the answer is command recursive-edit. Just use M-x recursive-edit to open a recursive edit. You can also bind this command to a key, of course.
(If the minibuffer is active, then you normally cannot use M-x recursive-edit. In that case, bind a key in the minibuffer keymaps to recursive-edit. Or you can set option enable-recursive-minibuffers to non-nil, to be able to invoke M-x recursive-edit from a minibuffer.)
You enter a recursive edit by calling recursive-edit, but there is no default binding which invokes this anywhere (and doing so arbitrarily might be hazardous).
In the case of query-replace there is some special-case handling which goes on when you type C-r which saves the current match data/point/mark/buffer/window configuration before entering the recursive edit, to ensure that it can restore things when you exit from it.
This need to wrap some situation-specific custom handling around calls to recursive-edit is very common to the existing use-cases, so there might not be a safe way to invoke it generally.
My guess is that custom handling would certainly also be needed to support it during an isearch, and I see no such facility.
Do note that Emacs pushes point to the mark ring when you begin an isearch; so for your specific use-case you would simply jump to & pop the mark with C-uC-SPC
From your workflow description, I'm not sure you really need recursive edit mode.
When you do a search in emacs, the current point is saved. On my system C-r is reverse isearch. When I hit it, I'm prompted for the search string and hit enter. This takes me to the first 'hit'. Hitting C-r againi takes me the next hit etc. Once you find the text you want, provided you don't hit enter, you can read the code and then hit C-g to cancel the search. This will jump your cursor back to the point where you started the search. This is fine provided you can see all the code you want to read on screen.
When you can't read all the code on screen and you need to move around in the buffer, you have to hit enter. Once you do this, you have lost the saved point and I suspect this is where you thought of using a recursive edit mode so that you can jump back once you finish. However, this won't work quite as you want because as soon as you hit enter to select the searched for string, you will come out of recursive mode and lose the saved point.
There are a couple of ways to fix this workflow to achieve what you want. In fact, your workflow is quite a common requirement. Because of this, many programming modes already have this functionality built in. Therefore, the first thing to do would be to ensure your mode doesn't already have this - it is probably called something like jump to definition or similar.
If your mode doesn't have this support, then you can get what you want by saving the point and then jumping back to it later. This is a really handy technique. All you need to do is C-SPACE twice. Then later, after moving the point to a new locaiton, you can just do a C-u C-SPACE to jump back to that point. From the emacs manual
Instead of setting the mark in order to operate on a region, you
can also use it to “remember” a position in the buffer (by typing
‘C-SPC C-SPC’), and later jump back there (by typing ‘C-u
C-SPC’). *Note Mark Ring::, for details.
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 get this warning in my matlab-shell buffer when I print alot to stdout:
Warning (undo): Buffer `*MATLAB*' undo info was 12268000 bytes long.
The undo info was discarded because it exceeded `undo-outer-limit'.
This is normal if you executed a command that made a huge change
to the buffer. In that case, to prevent similar problems in the
future, set `undo-outer-limit' to a value that is large enough to
cover the maximum size of normal changes you expect a single
command to make, but not so large that it might exceed the
maximum memory allotted to Emacs.
My emacs looks like this:
I really don't need any undo in the matlab-shell which is the right buffer. Is there a way to disable this warning? Note that the left buffer is a MATLAB script which means that the major mode is MATLAB, and certainly undo should not be disabled there.
As that warning message says (or used to say?):
You can disable the popping up of this buffer by adding the entry
(undo discard-info) to the user option warning-suppress-types,
which is defined in the warnings library.
That is:
(add-to-list 'warning-suppress-types '(undo discard-info))
(That will of course just disable the warning, not the undo data collection itself.)
Your question is a little ambiguous, but assuming you're saying that you have no need to undo things in this buffer, then you can disable the undo system on a per-buffer basis:
buffer-disable-undo is an interactive compiled Lisp function in `simple.el'.
(buffer-disable-undo &optional BUFFER)
Make BUFFER stop keeping undo information.
No argument or nil as argument means do this for the current buffer.
So you can call M-x buffer-disable-undo RET interactively, or if you're sure about it, you could add this to a hook function for the mode in question.
Edit:
So based on the extra information in the question comments, I would suggest this:
(add-hook 'matlab-shell-mode-hook 'buffer-disable-undo)
Emacs usually use Ctrl+G to cancel the operation ,but when i use the GUD mode to debug a program ,the Ctrl+G is usually not working so well as i expected.
For example, if i wanna to set a break point at the source test.cpp, line 223,
if i input
"b test.c:" ,then i use the TAB to auto complete it then will try to list all the possible result , then the emacs cannot respond to any input.
if i use Ctrl+G to cancel this, the result continue to output all result to the screen, this may take a long time.
is there a way to cancel this action more effectively?
Ctrl+G is for cancelling Emacs commands, but that output is coming from the debugger that's being run in the comint buffer. The Emacs command has already completed, it just sent the TAB to the debugger process.
Try Ctrl+C Ctrl+C, which sends an interrupt to the subprocess. However, it's possible that the subprocess has already finished sending the list of results, and it's all in the pty buffer.