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)
Related
There are some kind of buffers in Emacs, that are readonly and thay can be closed on q key.
For example, search functionality in projectile (C-c p s g) opens search results buffer which can be closed just pressing q key.
What name of this kind of buffers in Emacs terminology and how to manage them programmatically?
In general, read-only buffers which can be closed with q are likely to have the major mode special-mode, or some derivative thereof.
See C-hig (elisp) Basic Major Modes RET
This kind of buffers in temporary buffer.
You can put your output to temporary buffer using with-output-to-temp-buffer function
A good article about this - Emacs: Capture Shell Command Output in Temporary Buffer
The question is unclear. Temporary buffers do not necessarily bind q to quit or anything similar. Keybindings of temporary buffers are not necessarily similar at all. Look at *Messages* and *scratch*, for example.
There is no single definition of "temporary" buffer in Emacs. That term just means (roughly) any buffer that a user is not likely to save or want to save. In general, any non-file buffer could be thought of as temporary.
Buffers for which q performs some sort of quit operation are not necessarily temporary either, but they often are (not expected to be saved). You can save any buffer using C-x C-w - a *Help* buffer, for instance. And even when q quits the window or buffer in some sense, the exact behavior can be quite different from one buffer to another.
Finally, user settings can affect what things like q (quit) operations do. And they can depend on the particular buffer as well.
In short, the question is not specific enough to draw a helpful answer. But perhaps some of the above can help a general understanding. My suggestion is to pose another, very specific question.
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 was wondering how people manage with the useless messages etc emacs buffers generated randomly, for example after my completions, I get an completions buffer and it upsets me it create a buffer I have to traverse to get to the next buffer. Anyone have a solution to this?
The title is rather vague. There are lots of Q&As on the general subject of "buffer management" in Emacs. Here's one which includes links to several others (see "Linked" in the right-hand sidebar):
How can I more easily switch between buffers in Emacs?
For your specific question, I suggest using the excellent winner-mode. Just add (winner-mode 1) to your .emacs file (or type M-x winner-mode RET to try it out).
Once enabled, you can call winner-undo with C-c<left> (repeatedly, if necessary) to step backwards through all the previous window configurations.
Thus, when a window pops up and you no longer want it, you type C-c<left> and you're immediately back to how things were before.
C-c<right> calls winner-redo which restores the configuration you started with (i.e. it doesn't step through the configurations like the undo command).
Also note that many types of buffer can be buried with q or deleted with z.
I have a number of splits open, looking at various buffers. But when I for example check the help on a function it will replace one of the splits with the help buffer. Once I'm done reading the help I have to go back to the correct buffer manually which is a pain. How do I get Emacs to be nicer to my buffers?
Update: Help will let you press q to go back to the previous buffer. But causing the Emacs backtrace to pop up also steals one of my buffer windows and it doesn't have a q.
Update: Backtrace DOES have q to go back. My original question still remains: how do I ask Emacs not to steal one of my splits?
Adding the line(push "*Help*" special-display-buffer-names) to the init file should make subsequent invocations of the help buffer to appear in its own frame(what the desktop usually calls "window"), and leave the original frame with its configuration alone.
See Special Buffer Frames.
You could also use winner-mode. It came up on planet.emacsen.org a while back.
Winner Mode is a global minor mode. When activated, it allows to “undo” (and “redo”) changes in the window configuration with the key commands ‘C-c left’ and ‘C-c right’.
That way you can undo any changes to your splits immediately after they happen.
I hope this will help you :
C-x 0 to remove the current window
C-x 1 to keep only the current window
you can use windmove by adding the following line in your .emacs :
(windmove-default-keybindings)
Then, you can move the point between windows using S-right S-left S-up and S-down
There are lots of ways to store and restore emacs windows, see emacswiki.org on the subject.
What I do is just go to that changed buffer, C-x k it, and the current buffer in that window will be the previous buffer.
It may be possible to define advice for the help that saves the current window and buffer state and restores it with a simple keybind. But this is outside my basic elisp knowledge.