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-alistthen 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.elmay 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.