I have searched in a number of places (1, 2, 3, 4) even looked at the e-lisp source files and could not figure out how to do, so I ask.


I have bound next-error to a key. I'm in some source code buffer and press the key. When walking to next error (compilation, grep, etc), emacs always makes sure to show the error buffer and the source code buffer.

What emacs does

The problem is, it insists in showing them in the same frame, splitting the current frame.

What I want

  • Always show source code / grep match in the window which happens to be selected at the time next-error is run.
    • never split that window (customizing split-*-threshold is not enough)
    • if next-error brings to another source file, show it in current window, no split, no new frame (dedicated buffers don't seem to be enough).
  • Regarding "compilation error"/"grep" buffer, if it is shown in any window, scroll to the appropriate line. Never split any window.

Accepted variants

Not to ask for more, but be more open to variations. For example, existing emacs logic may make some variants actually easier to implement:

  • Similar to what ediff does when switching to next difference, if a frame currently shows the compilation/grep buffer, then putting that frame on top is acceptable.
  • If no frame currently shows the compilation/grep, it is acceptable either to not show it, or to open a new frame showing it.

One possible implementation

  • Just removing any attempt to split or make buffer visible would be acceptable.

How to do that?

  • Just found a similar question and tried the suggested change. When advancing through grep results or compilation errors on the same file results it's great, but it causes emacs to open a new frame whenever a buffer change is needed, which is not what I want. I want the currently focused window to switch the next source file, yet still occupy the whole frame. Aug 27, 2018 at 12:44
  • One workaround would be selecting the source code frame and do M-: (set-frame-parameter nil 'unsplittable t). But that is attached to a particular frame, not change the general next-error behavior. Aug 27, 2018 at 13:22
  • 1
    A hacky solution if there are not other windows in the same frame you are bothered with : bind your key to (lambda() (next-error) (delete-other-windows))
    – Jeeves
    Aug 27, 2018 at 16:34

1 Answer 1


Something like this?

(defun my-compile-goto-error-condition (_buffer _action)
  "`display-buffer-alist' condition callback."
  (member this-command '(next-error previous-error compile-goto-error)))

(defun my-display-buffer-full-frame (buffer _action)
  "`display-buffer' function."
  (let ((window (display-buffer-same-window buffer nil)))
    (delete-other-windows window)

(add-to-list 'display-buffer-alist '(my-compile-goto-error-condition
                                     . (my-display-buffer-full-frame)))
  • IIUC, this says "whenever compilation/grep features used, also make current buffer fill-frame". This feels a little hackish yet is an interesting progress compared with the previous workaround M-: (set-frame-parameter nil 'unsplittable t) because it works in all frames. Aug 28, 2018 at 8:58
  • There is a drawback, though. If I manually take care that the compilation/grep buffer match buffer (not source code buffer) is visible somewhere, I can see the small triangle advancing as I walk the matches, but the buffer would not scroll to maintain visibility of that triangle, a benefit that plain next-error does. Aug 28, 2018 at 8:59
  • 1
    I'm not convinced my code actually does what I wanted it to, tbh. I think it's mostly working by side-effect :) I'm not going to follow it up right now, but it might give you other ideas to follow up on your own...
    – phils
    Aug 28, 2018 at 11:24

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.