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

[Juri Linkov]

>> I think such design looks overly complicated.  I hoped for something
>> much simpler by adding just a few lines to window.el.
>
> We have to make up our minds on what we want.  I think the primary aim
> is to display a series of related buffers in one and the same window.

The most reliable way to identify a series of related buffers
is to set a buffer-local variable in the origin buffer
to the window where outgoing buffers are displayed.

> Where and when do we want that?  So far we discussed two functions -
> 'vc-diff' and 'compile-goto-error'.  I think that at the very least we
> have to encompass all flavors of 'next-error' as well.

The feature should work for any possible command or buffer,
not limited to the small set of particular commands.

> Then we can look into how the clients of 'display-buffer' can support
> it.  Finally, we can decide how many lines of code we have to change in
> window.el.

Ideally, the users need to express their preference by a single alist entry.
For example:

  (use-previous-window . t) -- then all outgoing buffers will be displayed
                               in the same window

  (use-mru-window . t) -- then all outgoing buffers will be displayed
                          in the most recently used window
                          instead of the default lru

Or maybe a unified alist entry:

  (prefer . previous-window)
  (prefer . mru-window)