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?

  • I believe this is the answer to your question, which I wrote up 3 years ago at the beginning of my Emacs quest: stackoverflow.com/a/19415289/2112489 The applicable sections of code in 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.
    – lawlist
    Commented Apr 2, 2016 at 21:32

2 Answers 2


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?
    – Drew
    Commented Apr 3, 2016 at 15:59
  • 1
    It's probably for the obsolete options and the snark ("suffer").
    – user227
    Commented May 4, 2016 at 5:40
  • 1
    This 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....
    – AnoE
    Commented Jan 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 like display-buffer-alist.
    – Drew
    Commented Jan 21, 2021 at 5:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.