bug#45688: 28.0.50; New action for display-buffer?

[martin rudalics]

> Well, it's certainly the most common one, but having more than two
> windows in a frame isn't unheard of, either.

Right.  But how reconcile the two approaches?

> I think that makes sense...  if you have that mode enabled.  But if
> you're not asking Emacs to resize windows in this way, then having
> `display-buffer' resizing windows is somewhat confusing.

The one you cited earlier certainly is.  The basic idea is that a window
that was good for 'display-buffer' once, should be good again.  Unless
it shrunk in between.

>>> In related news, get-lru-window doesn't seem to work reliably?  I don't
>>> have a reproducer for that, either, but it seems to happen if I have a
>>> three window frame, and I call:
>>>
>>> (setq lru (get-lru-window (selected-frame) nil t))
>>> (window-bump-use-time lru)
>>> (get-lru-window (selected-frame) nil t)
>>>
>>> will then return the same window as `lru'...
>>
>> How do you "call"?  I suppose there's no chance to make another window
>> but the selected one the mru one.  We would have to look into the inner
>> workings of that "call".
>
> eval the expressions.

Where and how?   If you do that in the minibuffer window alone, you
should get a result not affected by 'select-window'.  Otherwise, all
bets are off.

martin