Subject: Re: bug#36161: 27.0.50; display-buffer-in-previous-window might choose not to use PREVIOUS-WINDOW

From: Dmitry Gutov <[email-masked]>
Date: Wed, 19 Jun 2019 04:37:53 +0300

On 16.06.2019 11:16, martin rudalics wrote:
>  >  > Hence it's more suitable for buffers popping up in special occasions
>  >  > (like, for example, when a bug occurred and the debugger should be
>  >  > entered) and less suitable for buffer editing.
>  >
>  > I have also noticed it's not always good for special buffers either, 
> e.g. if I run xref-find-definitions, press q, and run it again, 
> different windows will be used for the two times.
> 
> When a different window gets used there's usually a reason.  So I'd
> need a recipe to tell you more about this ...

OK, let's try again. The recipe is:

1. emacs -Q
2. Split the frame into 4 windows, so that new display-buffer calls 
don't pop any new windows.
3. Select the top-left window (for instance).
4. Call M-x project-find-regexp, input "Xref", press RET. The result is 
an *xref* buffer shown in one of the windows.
5. Press q.
6. Try 4. again.
7. Repeat 5,6 as many times as you like. The *xref* buffer will be 
displayed in all three available windows in turn.

>  > So about that main use case (the Debugger), can it just exclude the 
> selected window using inhibit-same-window? That would obviate the need 
> for special logic in this case.
> 
> An 'inhibit-same-window' entry is the canonical way to "exclude" the
> selected window.  A 'previous-window' entry is just a hint to "prefer"
> some other window.

I'm not sure if you're trying to say "no" in response to my question. 
But if so, I suppose this bug report can be closed (and we can conclude 
that this function is definitely not suitable for xref). Thanks for 
updating the docstring.