bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> 'display-buffer-in-previous-window' searches the buffer in the
>> prev-buffers list that 'switch-to-prev-buffer' might want to skip
>> (I still doubt this need).
>
> The need to skip or the need to search?

The need to skip.  If the original window was too small
to split and display the buffer in a new window below, then
if some existing window is reused to display the temporary buffer,
it's understandable for the user why that temporary buffer is shown
in the window-local tab-bar.

At least, then the user will see in which window the same buffer
will be reappear again - in the same window that shows this buffer
in its window-local tab-bar.

>> I proposed to generalize display-buffer-in-previous-window
>> to avoid duplicating code like in debug.el that uses
>> debugger-previous-window, debugger-pre-previous-window,
>> debugger-previous-window-height because the same feature
>> is needed in other packages like edebug.el.
>>
>> The same feature is needed also for next-error to display hits
>> from different buffers in the same window.
>
> When a user can always make a new window there is indeed no problem:
> place or reuse the window below the selected window or on the bottom
> of the frame.  Both approaches are sufficiently deterministic in their
> choice of a window.

I agree.

> But as soon as a window must be reused and the selected one is at the
> bottom of the frame, it can become quite difficult to assure that a
> buffer shows up in a deterministic location.  This eventually gave
> raise to the idea of introducing 'display-buffer-in-previous-window'
> (together with the fact that a window's previous buffers then became
> easily available via 'window-prev-buffers').

The second time when the buffer is displayed again in a previous window
is deterministic.  But the first time it is non-deterministic - it's
displayed in a random window.  At least, the user can't predict the
window where it will be displayed - thus the surprise factor.
With get-mru-window instead get-lru-window the place is more
deterministic because the user usually remembers which window is mru.

>> Or better to obviate the need in all this complex special handling
>> simply by removing the get-lru-window rule in the default action,
>> thus replacing it with get-mru-window.
>
> When people work with two windows simultaneously, the mru one is
> usually the "other" window they work with, maybe showing the same
> buffer at a different location.  I think it would be a bad idea to
> punish such users by reusing the other window for showing some
> temporary buffer instead.

Right.  Neither lru nor mru should be used to steal existing windows
from users to show temporary buffers.  Only new windows should be
created below or on the bottom.

But my complaint about get-lru-window is that it prevents me from
using more than two windows.  When I create three windows or more,
then get-lru-window always selects a wrong window.  Is it possible
to change get-lru-window to get-mru-window to allow using three windows
and more on the same frame?