bug#70949: display-buffer-choose-some-window

[martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

 > This is exactly what I already use in ~/.emacs, and it works nicely.
 > Any chance to add something like this optionally to window.el?
 >
 > (defvar-local display-buffer-previous-window nil)
 >
 > (add-to-list 'display-buffer-alist
 >               '((category . compilation)
 >                 display-buffer-in-previous-window
 >                 (previous-window . display-buffer-previous-window)))
 >
 > (define-advice compile-goto-error (:around (ofun &rest args) previous-window)
 >    (let ((buffer (current-buffer)))
 >      (apply ofun args)
 >      (with-current-buffer buffer
 >        (setq-local display-buffer-previous-window (selected-window)))))
 >
 > The main problem is where to set this buffer-local variable
 > (I think better to use the buffer-local variable instead
 > of the window parameter since visiting results from rgrep
 > is a property of the buffer, not the window).
 > Instead of the advice like above, 'display-buffer-previous-window'
 > should be set in every buffer displayed by 'display-buffer'.
 > Isn't setting this variable in all buffers too excessive?
 > But I see no other way because the user might want to
 > force displaying the results in the same rgrep window, then
 > display-buffer-in-previous-window should reuse the same window.

We are talking about displaying, in one and the same window, buffers
whose only relationship is that they appear in the results list of
compilation or grep output.  That's why I think that a buffer-local
variable doesn't make sense here.  It works for 'compile-goto-error' but
only if, as a user, you invoke 'display-buffer' from the results window.
If you are in the file window and want to display the next file, you
have to go back to the results window.  If you use one window to show
results and files, you have to redisplay the results in that window
first.  All this is tedious, especially given the fact that 'next-error'
already can guess from where to get the name of the next file to show.

I think we need a unified framework that supports 'compile-goto-error'
and 'next-error' out of the box, where the later command can be invoked
from anywhere (although the key-binding in the results buffer is
obscured by 'compilation-next-error').  Which means that we should use a
global variable, say 'compilation-previous-window', that these commands
use to show the next file buffer.

This variable should be set up by the first invocation of either
'compile-goto-error' or 'next-error' and should be reset by
'quit-window' and 'delete-window'.  In addition, we'd need
'grep-previous-window' and 'occur-previous-window' variables and
whatever else falls into this category.

'next-error' could first determine, as it does now, to which category
the user request belongs.  If it's the compilation category, it consults
'compilation-previous-window' and, if that's a live window, calls
'display-buffer' with a 'display-buffer-in-previous-window' action and
'compilation-previous-window' as 'previous-window' action alist entry.
If it's not a live window, it has to first find or make a suitable
window, set 'compilation-previous-window' to that window and maybe mark
the window as softly dedicated so it won't get used too soon by other
'display-buffer' calls.

Whether all this should be done by 'next-error' or within
'display-buffer' is to decide.  In the latter case, 'next-error' could
pass to 'display-buffer' a 'previous-window' entry whose value is
something like the symbol 'compilation-previous-window' and
'display-buffer' would have to do the work I sketched above.  This has
the advantage that 'compile-goto-error' could use the same underlying
mechanism and no code would be duplicated.  The disadvantage is that
people who know about the inner working of compilation buffers and
'next-error' would have to work within window.el.

martin