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')?
>
> I don't understand what would happen with this.

An alist entry describes what should happen at the time a buffer is
shown.  'debugger-bury-or-kill' describes what should happen when a
buffer is unshown, something which may happen long after showing it.
So we have to remember the thing to do at unshow time (probably in a
window parameter) and make the unshow code aware of it when it runs.

>> 'try-windows' sounds too active for an alist entry - we would have to
>> use 'windows-to-try' instead.
>
> If you want more declarative names, then what about 'candidates' or
> 'default-window'.

Both could apply to any action function: I'd prefer something that can
be attached to specific action function like 'windows-to-use' or
'some-windows' for 'display-buffer-use-some-window' and
'windows-to-split' or 'pop-up-from' for 'display-buffer-pop-up-window'.

>> 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.
>
> Maybe use names like in WindMove: action 'display-buffer-in-direction'
> and an alist entry '(dir . right)' where the default is '(dir . below)'

For example.  The question is whether any such 'dir' should apply to
using, splitting or both.  That's why I'd rather include the direction
separately in the 'windows-to-use' and 'windows-to-split' entries or
whatever we call them.

That is we have to decide whether we make one entry dedicated to each
buffer display function or make entries that apply to more than one
such function.  We have the latter already for the 'side' entry and
I'm not sure whether I like it because it's not always clear whether
two action functions are mutually exclusive: Now hardly anyone would
ever want to _facultatively_ display a buffer in a side window or an
atomic window.  But when we want 'side' to refer to where a new window
should be created or (re-)used I'm not entirely sure.  I know that
'display-buffer-below-selected' and 'display-buffer-at-bottom' both
implicitly fix the side (or direction) for both, using and splitting,
and that's OK but maybe not all applications might want it.

martin