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

 > Sorry, I don't understand why the design should be limited to
 > compile-goto-error/next-error only.

That's what I keep saying here all the time.

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

I don't think that one defcustom will do.  And if we try building on
what 'next-error' finds for us, buffer-local variables won't help
either.

The common underlying principle is that a user starts an operation to
display several file-visiting buffers in a row triggered by some sort of
operation on these files like a compilation, grep, or version control
action.  That action usually produces a buffer I call "results buffer"
and sequentially scanning that buffer will produce "file buffers" that
should be handled in a specific way.  So we need:

- A method for extracting a list of file names from the results buffer
   (not needed if the results buffer contains them already but in my
   experience these file names are often relative only).  Obviously, this
   is already done for each of the contexts we want to address but it
   would be nice to have some unified approach here: A list of absolute
   file names and a pointer to which is the one to be displayed next.

- A method for displaying the first file buffer.  It will decide whether
   the file buffer replaces the results buffer in its window, uses some
   other window on the same frame or even another frame...  And it will
   set up the '...-previous-window' variable specifying the window that
   should be used for displaying the remaining file buffers.

- Key-bindings for displaying the next and previous file buffers from
   _any_ window selected.  Ideally, these would be M-n and M-p.

- A method for quitting.  Deleting the file buffer window (or frame) is
   one way to do that.  Invoking M-n with the last file buffer current
   could be another way - possibly after a 'quit' prompt.  Otherwise,
   'quit-window' and the 'quit-restore' parameter should handle that,
   where the latter would have to be set up when displaying the first
   file buffer.

The major customizable thing I see here is the method for displaying the
first file buffer and I think that that should be done for each type of
results buffer separately.

martin