3

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.

Context

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?

Stéphane Gourichon
  • 431
  • 3
  • 16
  • Just found a [similar question](https://emacs.stackexchange.com/questions/16456/how-can-i-force-emacs-to-never-split-frames-in-particular-for-compile-goto-erro?rq=1) 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. – Stéphane Gourichon Aug 27 '18 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. – Stéphane Gourichon Aug 27 '18 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 '18 at 16:34

1 Answers1

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)
    window))

(add-to-list 'display-buffer-alist '(my-compile-goto-error-condition
                                     . (my-display-buffer-full-frame)))
phils
  • 48,657
  • 3
  • 76
  • 115
  • 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. – Stéphane Gourichon Aug 28 '18 at 08: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. – Stéphane Gourichon Aug 28 '18 at 08: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 '18 at 11:24