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

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

> 'display-buffer' still lives in the paradigm of <= 2 windows frames set
> up in the past century and probably still the only reasonable one for
> TTY frames.  For that it supports things like 'even-window-heights' and
> a 'split-height-threshold' of 80 with its "If, however, a window is the
> only window on its frame, or all the other ones are dedicated,
> ‘split-window-sensibly’ may split it vertically disregarding the value
> of this variable." exception.  Hence a first step to get your rampages
> produce more reasonable results might be to ask whether that paradigm is
> still a valid one.

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

> If we don't want to do that, we can try to do some cosmetics in the size
> restoring mechanism.  Basically, that mechanism is used when you display
> a temporary buffer in a two windows layout and you have
> 'temp-buffer-resize-mode' enabled.  Suppose with emacs -Q you enable
> that mode and type C-h f push RET and then C-x 4 f to find some file.
> This will re-enlarge the window used for showing the 'push' help to its
> prior size so you get what you intend for showing that file.

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.

> If we want 'display-buffer-use-some-window' to not do such size
> restorations, we can just add a 'do-no-restore-size' alist entry and an
> appropriate check like
>
>       (when (and (not (cdr (assq 'do-no-restore-size alist)))
>                  (listp quad)
>                  (integerp (nth 3 quad))
>                  (> (nth 3 quad) (window-total-height window)))
>
> 'display-buffer-use-least-recent-window' (and/or the application/user)
> could then set that entry at their like.

Makes sense.

>> 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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no