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

[martin rudalics <rudalics@gmx.at>]

 > This fixes the reproducer, but not the case of actually jumping around
 > manually -- `M-x display-buffer' sometimes chooses to resize the
 > windows.  :-/

Have you ever read the Elisp manual where it says

      ‘display-buffer’ is not overly well suited for displaying several
      buffers in sequence and making sure that all these buffers are
      shown orderly in the resulting window configuration.  Again, the
      standard action functions ‘display-buffer-pop-up-window’ and
      ‘display-buffer-use-some-window’ are not very suited for this
      purpose due to their somewhat chaotic nature in more complex
      configurations.

Maybe you bumped into this with your experiments, in particular when
trying to reuse a window that you've already used before.

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

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.

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.

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

martin