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.
Related
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.
I'm a developer who uses emacs. In emacs I use multiple frames (what most people would call X windows), and the compile function for my builds. I like to have one frame for my compilation buffer, and the others for source. That allows me to navigate to build errors easily and get a nice big view of the source I'm investigating along side a nice big view of my build output. This works fine when I use the 'next-error' function from a source frame.
But when I move my pointer into the compilation frame, and click on an error, it vertically splits that frame to show the relevant source. I want it to show the relevant source in one of my other frames.
Is there a way to "lock" a frame so that it won't be split into windows, and so other frames will be used instead? I'm OK if it splits one of my other frames to display the new source files - just not the compilation frame (because that means I have to unsplit that frame and then switch the buffer of a different frame to display the buffer in question - that's cumbersome).
Alternatively it would be fine if I could use a different mouse button on an error in the compilation buffer to say "visit this file and line in a different frame".
I believe you can achieve your goals by making the window in your "compile frame" dedicated:
Functions for displaying a buffer can be told to not use specific windows by marking these windows as dedicated to their buffers.
Interactively, M-x set-window-dedicated-p should make your window dedicated.
From elisp, something like
(set-window-dedicated-p (selected-window) 1)
should do the same. Replacing 1 with t will make the window strongly dedicated:
As a special case, if flag is t, window becomes strongly dedicated to its buffer. set-window-buffer signals an error when the window it acts upon is strongly dedicated to its buffer and does not already display the buffer it is asked to display. Other functions do not treat t differently from any non-nil value.
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)
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 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.)