bug#32825: 27.0.50; Deterministic window management

[Juri Linkov <juri@linkov.net>]

>> Regarding TAGS, I spend much time killing TAGS buffers, but they
>> quickly reappear in the buffer list like in a whac-a-mole type of game.
>> Shouldn't such internal types of buffers be named with a leading space
>> in their buffer names?
>
> Etags files are called TAGS and we usually set the buffer name from
> the name of the file it's visiting.  We should be able to prepend a
> space but I have no idea where and when we visit the TAGS file.

This is easy to fix, but I'm not sure if this might break some packages
that depend on TAGS buffers with original names.

>>> I'd rather restart with a buffer from the window-local list
>>> provided that list is "long enough".  That's fuzzy to implement.
>>
>> You mean a cyclic window-local buffer list?
>
> If it's long enough, yes.  Note also that once a member of the global
> list has been taken it will pollute the local list forever thus also
> needlessly increasing the list of previous buffers for a window.
>
> More precisely, the problem is that of "navigational security"
> (alternating 'switch-to-prev-buffer' and 'switch-to-next-buffer' calls
> should reliably reproduce the buffer previously shown in a window to
> avoid violating the principle of least surprise) vs "minimum
> annoyance" (that of not switching to a buffer a user expressly doesn't
> want to see).
>
> So I think that while the solution is to not allow
> 'switch-to-prev-buffer' to switch to such an unwanted buffer, we
> should allow 'switch-to-next-buffer' to switch to it.  But I haven't
> yet thought about all the implications.
>
> Also I'm not sure whether we should maintain for each window separate
> lists of buffers we do not want to switch to but we might want to
> consult in 'display-buffer-in-previous-window' or to leave such
> buffers in the windows' lists of previous buffers and have
> 'switch-to-prev-buffer' skip such buffers with the help of some
> predicate.  The latter would be more likely the way to go because we
> then could allow a simple user option to provide that predicate.

Maybe better to represent a list of prev/next buffers as a tree?
Then inserting a new buffer inside it will create a leaf that
can be ignored for navigation.  An analogy of this is undo-tree.