I am using gdb under emacs. During a debug session, when emacs/gdb jumps to source code i usually open up another frame (C-x 5 2) and pull that onto my second monitor.
The problem comes when a new source code file needs to be opened (for example when the program enters a function defined in another source file, walking the stack, etc ...) emacs tends to automatically open up the corresponding source code in a new window, but unfortunately in the gdb frame.
I would like for it pull up new source code in the new frame i opened up and leave the gdb frame completely untouched. My question then is this:
How can i set emacs to open up any new file such that the file is displayed in the new frame?
I hope i am making sense.
Not a simple answer, but an appropriate entry in display-buffer-alist could tell display-buffer to always use the frame you want as the destination for new buffers.
In 24.1, the doc is:
display-buffer-alist is a variable defined in `window.el'. Its value
is nil
This variable may be risky if used as a file-local variable.
Documentation: Alist of conditional actions for `display-buffer'. This
is a list of elements (CONDITION . ACTION), where:
CONDITION is either a regexp matching buffer names, or a function
that takes two arguments - a buffer name and the ACTION argument of
`display-buffer' - and returns a boolean.
ACTION is a cons cell (FUNCTION . ALIST), where FUNCTION is a
function or a list of functions. Each such function should accept
two arguments: a buffer to display and an alist of the same form as
ALIST. See `display-buffer' for details.
`display-buffer' scans this alist until it either finds a matching
regular expression or the function specified by a condition returns
non-nil. In any of these cases, it adds the associated action to the
list of actions it will try.
You can customize this variable.
This variable was introduced, or its default value was changed, in
version 24.1 of Emacs.
Related
When I press M-. or C-c C-l it usually jumps to the function's declaration in .mli file. Oftentimes there is associated .ml file to which I can switch with C-c C-a but then, I have to search for the implementation of this function in it manually.
If there is an easy way to either jump directly to a definition in .ml file or somehow position to the corresponding function location when switching between .mli and .ml?
This is governed by the merlin-locate-preference variable, which documentation says:
Determine whether locate should in priority look in ml or mli files.
So you will land to the implementation, if it is available, once the variable is set to 'ml:
(setq merlin-locate-preference 'ml)
It is interesting though, that it defaults to 'ml so that either you overwrote it or merlin jumps to mli because it can't find the definition. If you want to jump to the definition in another project, then add corresponding S and B clauses to your .merlin file.
I use M-. to jump to definitions of class/functions. Sometimes there are multiple classes with the same tag, so I need to use C-u M-. to jump to multiple files, hence multiple buffers. Now my question is, how do I go back to the original buffer quickly? I know C-x b, but you need to type in the buffer name, or it just give you by default the last buffer you visited, is there anyway to go further? For example, go to the previous buffer of the last buffer?
I believe that M-. calls find-tag by default. You should be able to go back up the stack of locations with M-* (pop-tag-mark).
From C-h f find-tag:
A marker representing the point when this command is invoked is pushed
onto a ring and may be popped back to with M-*. Contrast this with the
ring of marks gone to by the command.
Icicles multi-command icicle-find-tag, bound to M-. in Icicle mode, combines all of what vanilla Emacs commands M-. (find-tag), M-, (tags-loop-continue), tags-apropos, and list-tags do. And it does more.
You can complete against any tags, cycle (in different orders) among a subset of tags matching an additional pattern, and so on, visiting multiple tags in a single command invocation. You choose the tags you want to visit, in any order --- you need not visit each one in sequence.
You first enter (using RET) a regexp that all tags you are interested in must match (it could be vacuous, to get all tags).
After that, you can type a pattern that a subset of the tags and or their source files must match.
That is, by default you can complete against multi-completion candidates that are composed of the tag itself and its source file name.
You can choose candidates to visit using C-mouse-2 in *Completions* or by cycling among their names using down and up and then using C-RET to visit.
You can return to your original location using M-* (icicle-pop-tag-mark). You can also return to it by just using C-g to finish your M-. invocation.
More information here.
I use winner-mode for this (and other similar situations).
Add (winner-mode 1) to your init file, and then when you wish to return to the window configuration that you were in before jumping to the tags, you just type:
C-c<left> to call winner-undo (repeating as many times as necessary)
If you had visited multiple tags in another buffer, this will get you back to your original buffer (or the previous buffer, at any rate) in a single step, rather than stepping back through the individual tags one by one.
If the tags have taken you through multiple buffers, then you'll need to type C-c<left> once for each buffer (or C-c<left>C-xzzz... if you'd gone on quite a long detour :)
I'd like to write an emacs lisp function that will write output to a window other than the current window. It should create a new window if only the current one exists, and it should use an existing one otherwise. This is similar to what happens when you run C-h-f (Describe Function), and the description pops up in another window. What is the best way to do this?
See display-buffer:
display-buffer is an interactive
compiled Lisp function in `window.el'.
It is bound to C-x 4 C-o.
(display-buffer buffer-or-name
&optional not-this-window frame)
Make buffer buffer-or-name appear in
some window but don't select it.
buffer-or-name must be a buffer or the
name of an existing buffer. Return
the window chosen to display
buffer-or-name or nil if no such
window is found.
Optional argument not-this-window
non-nil means display the buffer in a
window other than the selected one,
even if it is already displayed in the
selected window.
Optional argument frame specifies
which frames to investigate when the
specified buffer is already displayed.
If the buffer is already displayed in
some window on one of these frames
simply return that window. Possible
values of frame are:
`visible' - consider windows on all
visible frames.
0 - consider windows on all visible or
iconified frames.
t - consider windows on all frames.
A specific frame - consider windows on
that frame only.
nil - consider windows on the selected
frame (actually the last
non-minibuffer frame) only. If,
however, either
display-buffer-reuse-frames' or
pop-up-frames' is non-nil (non-nil
and not graphic-only on a text-only
terminal), consider all visible or
iconified frames.
Or you can use pop-to-buffer if you want that buffer to be selected (which it sounds like you don't), or with-output-to-temp-buffer which binds the standard-output to be sent to the temporary buffer - read the documentation for more details (hat tip to Michael for that).
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.)