Sometimes when in comint mode the point is anywhere in the buffer and I press Return by mistake. This sends the text at point to the underlying process, which can be really dangerous. Often this text contains many lines and, by chance or not, one of them could be a valid command.
Is there any way to tell comint not to execute anything on Return except the last input?
The documented way seems to be override comint-get-old-input variable with a custom function. Easiest will be something like this:
(setq comint-get-old-input (lambda () (end-of-buffer) (comint-get-old-input-default)))
It goes to the end of buffer first, and only then calls coming-get-olt-input-default, effectively not messing with the previous output. Put it in your init.el, brief testing shows that it works.
Related
I'd like to know if there's some way not be prompted with: "Buffer changed, save first? (y or n)" everytime I execute the buffer [C-c C-c] after some change. I came across the variable py-ask-about-save, which has the following documentation:
If not nil, ask about which buffers to save before executing some code.
Otherwise, all modified buffers are saved without asking.
which is a behavior I could accept. However
(setq py-ask-about-save nil)
has no effect. Is there some other thing I should be aware of?
Indeed, it would be even better if C-c C-c had no effect saving any buffer, but only be responsible for executing the code.
The variable py-prompt-on-changed-p appears to be what the O.P. is seeking. The doc-string states:
When called interactively, ask for save before a changed buffer is sent to interpreter.
See also line 10284: http://bazaar.launchpad.net/~python-mode-devs/python-mode/python-mode/view/head:/python-mode.el
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'm probably going down the wrong path here, so let me know if I am. I'm trying to build a similar user interface to that which Vim's ctrlp and other plugins use, whereby the user is given a prompt, and as they type, results are shown above the minibuffer prompt line.
I've gotten the minibuffer command handling part working fine with minibuffer-with-setup-hook and a local post-command-hook (easy) and can get the results I want to display (verified by just (message)ing them for now).
If I want to show, say, 10 lines of results above that minibuffer prompt line, should I be somehow prepending text to the minibuffer, or using a separate buffer that I'll close once the command finishes? Any pointers to parts of the manual I should be reading to be on the right track with this?
The "minibuffer" is a normal buffer, so you can modify it by inserting/deleting text into it in the normal way. This said, adding text "before" means basically modifying the prompt which might lead to problems down the line. You'll probably be much better off doing something like
(let ((ol (make-overlay (point-min) (point-min))))
(overlay-put ol 'before-string (format "%s\n" myresults)))
I started to write this as a comment, but it got a bit too long ...
TBH, I feel there is room for a lighter weight version of helm. But the reality is helm is good enough, and someone else has already written it.
Neither I nor anyone else (so far) is motivated enough to rewrite it. What you describe as "God" aspect of it is indeed unappealing. But it is possible to load it (huge as it is, with modern computers, it really isn't an issue), and change settings so it is minimalistic.
ido is a simpler alternative, but the style of UI is not exactly how you described.
I'm trying to write a plugin that calls a function (icalendar-import-file) which has the nasty side effect of opening between 1 and 3 buffers every time it is called, and sometimes I want to call it a whole bunch of times.
I can't even find a function that will list buffers without popping up a new buffer, which is a little frustrating.
As far as I can tell that defun (ical...) doesn't return anything useful, so the two obvious solutions to me are to either: (1) set a variable to a list of buffers before I run the function, and then sweep through the buffers that exist after the function exits and delete the new ones, (something like save-excursion, but for buffers) or (2) somehow suppress the creation. It looks like ical... is pretty heavily dependent on this, though, so I'm not sure that that's feasible.
Are you looking for the function :
buffer-list is a built-in function in
`C source code'.
(buffer-list &optional FRAME)
Return a list of all existing live
buffers. If the optional arg FRAME is
a frame, we return the buffer list in
the proper order for that frame: the
buffers in FRAME's `buffer-list' frame
parameter come first, followed by the
rest of the buffers.
If you know which function is creating the unwanted buffers, and understand what effect removing them will have, you could always advise them (using after advice) to remove the unwanted buffer right at the source of the problem. I think this is safer than simply removing any new buffer once a function has finished.
I have a HTML page, with html-mode enabled. I call function sgml-validate to check for any markup errors. It's based on compilation-mode. I want to remove some warnings from the compilation output, so I wrote a function and hooked it to compilation-filter-hook (this variable is not documented, but compilation-filter invokes it). Everything works. My problem is that how can I ensure my filter function only gets called when I started the compilation process on a HTML page (via sgml-validate)?
I see two methods, but none of them worked:
First, I can check the value of major-mode. But it always returns compilation-mode, since that is enabled on the *compilation* buffer. (I found a filter function in the source code of grep+, and they did check the value of major-mode. I can't figure out how can it work correctly.)
The other idea was than to only hook my filter function to the HTML file's buffer, but for similar reasons it couldn't work as the output of compilation process goes to a seperate buffer.
It sounds like you can advise smgl-validate so that it performs the filtering before it performs all it's other operations. For example:
(defadvice sgml-validate (around fix-filtering command activate)
(let ((return-value ad-do-it))
(filter-function return-value))))
Meanwhile, I found that compilation-start accepts an optional argument mode, which will be the major mode for the compilation buffer. So I can create a major mode derived from compilation-mode, and define there my filter function now hooked to the proper buffer.
The only problem is now that sgml-validate does not allow me to set the mode argument on compilation-start, but that's another question.
(I don't consider this the ultimate solution, of course.)