I would prefer to have the *compilation*
buffer always stay in its own frame. However, currently if I run M-x compile
from another frame/window, the buffer pops up in a new window there as well. How can I cause emacs to instead only raise the existing frame which is displaying the *compilation*
buffer?
2 Answers
Normally, Emacs considers the selected frame the only reusable frame. In other words, normally Emacs only searches the current ("selected") frame for windows that already contain the buffer-to-display ("reusable windows"). What you need is for Emacs to consider the compilation buffer's frame as a reusable frame:
(push '("\\*compilation\\*" . (nil (reusable-frames . t))) display-buffer-alist)
The above snippet will make all the frames reusable when display-buffer
displays the *compilation*
buffer. Look at the documentation of display-buffer-reuse-window
to learn what other values reusable-frames
can receive.
However, this doesn't take care of the other direction - opening a code buffer from the compilation window. For example, if you open a buffer by pressing a link in the compilation buffer, Emacs will open the buffer in the same frame as the compilation window. Changing that is another matter. I don't know how the behavior compares with the special-display-buffer-names
solution.
Make buffer compilation always have a dedicated window. One way to do this is to customize option special-display-buffer-names
, to include "*compilation*"
. Another is to customize option special-display-regexps
, to include a regexp that matches that buffer name. (I include the regexp "[ ]?[*][^*]+[*]"
, which matches all buffers whose names are *...*
.)
(See also option special-display-frame-alist
, which you can use to specify the behavior and characteristics of the frame used for such special-display buffers.)
Emacs will tell you that these "special-display buffer" options are "obsolete", but thank goodness they are still supported. They offer a simple way to do what you want.
If you want to suffer through what Emacs prefers you do now, then customize option display-buffer-alist
instead. The idea is essentially the same (it's just an uglier and more complicated user option).
-
Care to explain the downvotes? Is there something incorrect in this answer?– DrewApr 3, 2016 at 15:59
-
1It's probably for the obsolete options and the snark ("suffer").– user227May 4, 2016 at 5:40
-
1This works very well, and except for the feature being obsolete it exactly solves OP's (and my ;) ) requirement. Selecting an error line in the compilation buffer correctly displays the source file in another frame, not in the special compilation frame. Really a shame, especially since the "official" way described in the other answer doesn't have a solution for this aspect, and also references to
special-display-buffer...
.– AnoEJan 20, 2021 at 16:34 -
@user227: Nothing snarky about that "suffer". If you use
display-buffer-alist
then you'll know what I mean. I think most, if not all, users lament how complicated it is. I think even its designer does, but nothing simpler yet just as flexible has been uncovered yet. Special-display is great (IMHO) for the simple cases it handles - it does that well. I don't think that feature should be obsolete just because we also need something general likedisplay-buffer-alist
.– DrewJan 21, 2021 at 5:07
compile.el
may have changed, and I have since made many changes/improvements to my custom functions that target certain frames for buffer display: stackoverflow.com/questions/18346785/… Take a look and see if the first link is approximately what you are seeking -- who knows, it may even still work without making changes.