Subject: bug#32825: 27.0.50; Deterministic window management

From: Juri Linkov <[email-masked]>
Date: Mon, 19 Nov 2018 01:01:37 +0200

>> Then maybe better to add such buffers to the end of the prev-buffers list
>> or to the end of the next-buffers list.
>
> We have that option in 'debugger-bury-or-kill'.  Do you mean to
> generalize it?

Yes, it could be moved to a new alist entry.

> OK.  What do you want to call it, 'windows-to-examine'?

Too long name.  Maybe better 'try-windows'?  Or 'reuse-window'
if this alist entry will be used in display-buffer-use-some-window.

> Shall we make it a list of function/frame pairs defaulting to
>
> '((get-lru-window . nil) (get-largest-window . visible) (get-largest-window . 0))
>
> where nil stands for whatever
>
> (or (window--frame-usable-p (selected-frame))
>     (window--frame-usable-p (last-nonminibuffer-frame)))
>
> returns?  Or do you want to control the DEDICATED and NOT-SELECTED
> arguments as well?  I hope that 'get-largest-window', 'get-lru-window'
> and 'get-mru-window' are 100% compatible wrt their arguments but
> haven't verified that yet.

I thought it could be a list of window types to try in the specified order,
for example:

(try-windows . (mru lru largest-visible largest-visible-and-iconified))

>> I don't understand what an alist entry you mean.  Or you mean adding
>> a new alist entry like (default-window . mru-not-selected)?
>
> For example.  To provide the 'windows-to-examine' sketched above you
> wouldn't want to specify an action function too.

But where this alist entry should be customized for all action functions?
I guess not in display-buffer-alist that specifies specific buffers.
Then where?  Maybe, in display-buffer-base-action with nil action and
non-nil alist that will be the default alist for all actions?