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

[Juri Linkov]

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

Sorry, I don't understand why the design should be limited to
compile-goto-error/next-error only.  I have the same problem with many
other commands.  For example, vc-diff from such buffers as *vc-dir*,
*vc-change-log* opens the diff buffer in unpredictable windows, every
time choosing another window that makes the window management unusable
(need to quit the buffer displayed in the wrong window and re-run the
diff command again).

As a unified framework we could provide a new defcustom with a list
of categories for which display-buffer will set a buffer-local variable
or the window parameter 'previous-window', then the next invocations
of the same command will reuse it.