unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Should tab-next cycle instead of stopping?
@ 2019-10-10 21:46 T.V Raman
  2019-10-10 22:09 ` Juri Linkov
  2019-10-11  3:02 ` Pankaj Jangid
  0 siblings, 2 replies; 5+ messages in thread
From: T.V Raman @ 2019-10-10 21:46 UTC (permalink / raw)
  To: emacs-devel

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 ...
-- 
Id: kg:/m/0285kf1 



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Should tab-next cycle instead of stopping?
  2019-10-10 21:46 Should tab-next cycle instead of stopping? T.V Raman
@ 2019-10-10 22:09 ` Juri Linkov
  2019-10-11  3:02 ` Pankaj Jangid
  1 sibling, 0 replies; 5+ messages in thread
From: Juri Linkov @ 2019-10-10 22:09 UTC (permalink / raw)
  To: T.V Raman; +Cc: emacs-devel

> 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 ...

Yes, it should cycle as in a ring, and this feature was implemented
5 days ago.  Please update from master and try again.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Should tab-next cycle instead of stopping?
  2019-10-10 21:46 Should tab-next cycle instead of stopping? T.V Raman
  2019-10-10 22:09 ` Juri Linkov
@ 2019-10-11  3:02 ` Pankaj Jangid
  2019-10-12 21:53   ` Juri Linkov
  1 sibling, 1 reply; 5+ messages in thread
From: Pankaj Jangid @ 2019-10-11  3:02 UTC (permalink / raw)
  To: emacs-devel

"T.V Raman" <raman@google.com> writes:

> 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.

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

--
Regards,
Pankaj Jangid



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Should tab-next cycle instead of stopping?
  2019-10-11  3:02 ` Pankaj Jangid
@ 2019-10-12 21:53   ` Juri Linkov
  2019-10-13  1:50     ` T.V Raman
  0 siblings, 1 reply; 5+ messages in thread
From: Juri Linkov @ 2019-10-12 21:53 UTC (permalink / raw)
  To: Pankaj Jangid; +Cc: emacs-devel

>> 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?



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Should tab-next cycle instead of stopping?
  2019-10-12 21:53   ` Juri Linkov
@ 2019-10-13  1:50     ` T.V Raman
  0 siblings, 0 replies; 5+ messages in thread
From: T.V Raman @ 2019-10-13  1:50 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Pankaj Jangid, emacs-devel

I can verify that it cycles correctly and I'm happy with it.

I'm adding emacspeak support and will likely add auditory icons as it
wraps around, but I dont want it to stop like isearch, like the present cycling.
-- 



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2019-10-13  1:50 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-10 21:46 Should tab-next cycle instead of stopping? T.V Raman
2019-10-10 22:09 ` Juri Linkov
2019-10-11  3:02 ` Pankaj Jangid
2019-10-12 21:53   ` Juri Linkov
2019-10-13  1:50     ` T.V Raman

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).