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

[Juri Linkov]

>> I meant switching to the window to instruct display-buffer what window
>> to use as mru, then switch back to the rgrep window.
>
> Who would switch to the window?  The user or 'display-buffer' itself?

The user.

>> We already have 'previous-window' that I'm using for a long time,
>> and it works nicely with such configuration:
>>
>> (defvar-local display-buffer-previous-window nil)
>>
>> (defun display-buffer-from-grep-p (_buffer-name _action)
>>    (with-current-buffer (window-buffer)
>>      (and (memq this-command '(compile-goto-error))
>>           (derived-mode-p '(compilation-mode)))))
>>
>> (add-to-list 'display-buffer-alist
>>               '(display-buffer-from-grep-p
>>                 display-buffer-in-previous-window
>>                 (previous-window . display-buffer-previous-window)
>>                 (inhibit-same-window . nil))
>>               ;; Append to not override display-buffer-same-window
>>               'append)
>>
>> (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)))))
>>
>> But this is very complicated configuration.  So I wanted to help people
>> to do basically the same with much simpler setting that overrides
>> the hard-coded 'lru' with just '(some-window . mru)'.
>
> I think that's what we want here and it should cover all sorts of
> 'next-error-function' too.  But 'get-mru-window' won't cut it.

I agree that 'get-mru-window' is too limited.

>> The only problem with '(some-window . mru)' is that its NOT-SELECTED is t,
>> so this excludes the very useful case of displaying the buffer
>> in the same selected window.  For example, with 'previous-window'
>> I often visit rgrep results in the same window where the rgrep buffer
>> was displayed.  This keeps everything confined to one window.
>
> We could provide two basic modes: One mode where the compilation, grep,
> or occur buffer is always kept visible and the file buffers are
> displayed in one or a few other windows.  And a mode where only one
> window is used.
>
> In either case we could use a window parameter, say 'next-window', that
> indicates that this window shall be used for the next 'display-buffer'
> call with a non-nil 'next-window' alist entry.  The value could be
> 'grep', 'occur' 'compile' or whatever we want so a user could do, for
> example, a grep within the outer context of analyzing compilation
> output.

Ok, I will throw out everything that I did, and will restart with your
function display-buffer-in-related-window.

> I see the following problems:
>
> - How to set up the 'next-window' parameter in the first call of a given
>   context.  IIUC we don't have a unique starting function for
>   establishing a suitable context of a series of related calls.  So
>   both, 'compile-goto-error' and 'next-error', would have to call
>   'display-buffer' with an appropriate 'next-window' entry.  For me,
>   it's been always confusing that 'compilation-next-error' does not
>   display the source buffer while 'next-error' does.

I don't understand why 'compilation-next-error' does not display
the source buffer?

> - How to remove/reset the parameter after the last call.  'quit-window'
>   should probably do that, but I'm not sure.
>
> - How to "nest" contexts when windows are shared.  If the same window
>   were used for displaying grep results within a compilation results
>   context, the 'next-window' parameter would have to become a list and
>   'quit-window' should probably pop an entry from it.

Nothing so complicated needed.  I will just adapt your starting point with
display-buffer-in-related-window to the useful configuration above.

Currently the main question is where to add display-buffer-in-related-window?
It should be added to display-buffer-fallback-action between
display-buffer-in-previous-window and display-buffer-use-some-window?
If not, then users should add it by customizing display-buffer-base-action?