Re: Should tab-next cycle instead of stopping?

[Juri Linkov]

>> If you have two tabs in the current frame, and you're in the first tab,
>> C-tab moves to the second tab. At that pointthe next C-tab appears to do
>> nothing, a subsequent C-tab moves to the first tab.
>>
>> Is that a bug or a feature?
>>
>> Would be nice if C-tab just treated the tabs in the current frame as a
>> ring that it cycles through ...
>
> I don't know if that is a feature or not but your email got me thinking.
>
> It would be a good idea if C-tab beeps at the last tab and a subsequent
> C-tab moves to the first tab. When there are lots of tabs open, this
> will give an indication that the user has reached the last tab.

IOW, should it be like isearch wrapping?  This has one problem:
when used with a numeric argument it stops at the end, e.g.
‘C-u 3 C-s’ doesn't jump to the third match from the beginning
of the buffer.  Instead, it stops at the end of the buffer and beeps.

Currently ‘C-u 3 C-TAB’ silently wraps to the next third tab
even from the beginning of the tab-bar with predictable outcome.

Signaling at the end of the tab-bar won't allow to visually calculate
and predict on what tab ‘C-u 3 C-TAB’ will arrive.

> And of course this is Emacs. This behaviour should be configurable.

Maybe configurable like multi-isearch-pause?

But before implementing this, I'd like to understand
if such overshooting is a real problem.  Isn't easy
in this case to go back with C-S-TAB?