bug#69993: Wrap window buffers while cycling

[Juri Linkov <juri@linkov.net>]

>> The problem is that from the point of view of tab-line users
>> currently there is no wrapping because the tab-line already
>> restricts itself to the buffers shown in that window only.
>
> I'm afraid we still misunderstand each other: For me "wrap" means that
> when I'm at the beginning of a list and want to go to its previous
> element, I go to the last element of the list.  When I'm at the end of a
> list and want to go to its next element, I go to the first element of
> the list.
>
> I think that if we added a 'switch-to-prev-buffer-wrap' option, we would
> emulate the behavior sketched above regardless of whether it's triggered
> by 'switch-to-prev-buffer' or 'tab-line-switch-to-prev-tab'.  Currently,
> 'switch-to-prev-buffer' always wraps while 'tab-line-switch-to-prev-tab'
> obeys the value of 'tab-line-switch-cycling'.

The users won't understand how currently 'switch-to-prev-buffer' always wraps,
when going to the previous element at the beginning of a list
doesn't go to the last element of the tab-line.

> 'tab-line-switch-cycling' could then be used to override the more
> general 'switch-to-prev-buffer-wrap' when calling
> 'tab-line-switch-to-prev-tab'.  Or we could alias
> 'tab-line-switch-cycling' to 'switch-to-prev-buffer-wrap'.  And we could
> use the term 'switch-to-prev-buffer-cycle' instead.

I think "cycle" is a wrong name.  Cycling is using
'switch-to-prev-buffer'.  But wrapping is going
from the beginning to the end of the tab-line.

>> But if you think that 'switch-to-prev-buffer-wrap' should be renamed
>> to something that makes no sense for tab-line users such as
>> 'switch-to-prev-buffer-restrict', then still it can be used
>> from tab-line.el like this:
>>
>> (when tab-line-switch-cycling
>>    (let-bind ((switch-to-prev-buffer-restrict tab-line-switch-cycling))
>>      (switch-to-prev-buffer window)))
>
> An option like say 'switch-to-prev-buffer-restrict' should effectively
> affect 'switch-to-prev-buffer' only.  'tab-line-switch-to-prev-tab'
> would not switch to a buffer never shown in that window and could be
> implemented as you sketched above.
>
> To sum up, I think that we should not mingle the concepts of
> wrapping/cycling and restricting into one and the same option but
> provide two options instead.

Mixing wrapping/cycling and restricting is unavoidable:
you can see how the previous patch reorders prev/next buffers
to make the order of tabs stay the same after wrapping.