|
From: | Dmitry Gutov |
Subject: | bug#36161: 27.0.50; display-buffer-in-previous-window might choose not to use PREVIOUS-WINDOW |
Date: | Wed, 19 Jun 2019 04:37:53 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 |
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 -Q2. 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.
[Prev in Thread] | Current Thread | [Next in Thread] |