bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

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

And act like a time-bomb via a window-parameter (like 'quit-restore')?

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

'try-windows' sounds too active for an alist entry - we would have to
use 'windows-to-try' instead.  And let's avoid 'reuse-window' in this
context - it's too ambiguous.  BTW we might also want to add a similar
entry for specifying the window we want to split (which means we could
easily generalize 'display-buffer-below-selected' and
'display-buffer-at-bottom' without having to add new action functions
like 'display-buffer-at-top' ...) and should reserve an appropriate
name for that.

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

... and lru-visible, lru-invisible?  BTW we could allow it to specify
using windows dedicated to another buffer as well.

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

Anywhere.  Why should we impose any restrictions here - either for the
user or for the application programmer?

martin