bug#32825: 27.0.50; Deterministic window management

[Juri Linkov <juri@linkov.net>]

>> 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.
>
> The latter is a visual feedback.  But if I blindly use C-x left, I'd
> still be surprised.

Then maybe better to add such buffers to the end of the prev-buffers list
or to the end of the next-buffers list.

>> 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.
>
> We can add an action alist entry to get the mru (or better
> mru-not-selected) behavior.  A small deal.

This would be very nice, thanks in advance.

>> 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?
>
> Earlier we discussed whether "creating a window" should also mean
> "using that window".  This could be yet another action alist entry -
> bump the use time of the window used for displaying a buffer even when
> it's not selected.

It seems the logic in most cases doesn't depend on creation time,
only on usage time like in mru.

> Something I notoriously forget in all my answers: Note that you need
> not add an action function in 'display-buffer-overriding-action' and
> friends.  Adding an action alist entry can often be sufficient to
> affect the remaining functions in the desired fashion.  I suppose you
> knew that already, but just in case ...

I don't understand what an alist entry you mean.  Or you mean adding
a new alist entry like (default-window . mru-not-selected)?