bug#69993: Wrap window buffers while cycling

[Juri Linkov]

>>> But this would mean to change the ordering of elements on the tab line
>>> whenever C-x b switches to a buffer already present on the tab line.
>>
>> Indeed, some hook is needed to restore the previous order after C-x b.
>> Maybe 'window-buffer-change-functions' like you suggested.
>
> And I think that in such case 'tab-line-switch-to-prev-tab' and
> 'switch-to-prev-buffer' should simply show different buffers.  That is,
> 'tab-line-switch-to-prev-tab' should _not_ use 'window-prev-buffers' to
> get the buffer to switch to but simply use the buffer represented by the
> tab visually preceding the current one on the tab line (stopping or
> using the last one on the tab line if there is no preceding one).

'C-x <left>/<right>' is too nice keybinding to lose ;-)
Therefore attempting to use it for navigating tab buffers.

>> So keeping the stable order of window prev/next buffers after C-x b
>> with a hook should be implemented in tab-line.el, not in window.el?
>
> I don't know how you currently handle C-x <left>, C-x b or
> 'rename-buffer' or whether a buffer is modified on the tab line so I
> can't tell whether you would need a hook for these.  But this issue is
> IMHO not connected to whether getting the previous or next buffer should
> wrap or be restricted to buffers previously shown in a window.

Handling 'C-x b' and 'rename-buffer' is not yet implemented.
Probably need to add a new window parameter to keep a list
of tab buffers and sync it with window prev/next buffers.