0

From Vim's :help tabs:

:tabp[revious] {count}
:tabN[ext] {count}
{count}<C-PageUp>
{count}gT   Go {count} tab pages back.  Wraps around from the first one
            to the last one.

While

:tabn[ext] {count}
{count}<C-PageDown>
{count}gt   Go to tab page {count}.  The first tab page has number one.

Finally, parameterless :tabn behaves consistent with :tabp and :tabp 1.

Why is that? Is it only to make 3gt jump to tab 3 instead of 3 tabs ahead? Nothing prevents vim from having :tabn 3 and :tabjump 3, and bind Ngt to use :tabjump rather than :tabn. Frankly, to me this looks like a design error.

Can we have :tabp N forward equivalent using only built-in commands? I noticed one can't use :tabprev -2, for example. If there is no built-in counterpart to :tabp N, then why have :tabp N at all?

2

Yes, this is inconsistent, but I also find the available choices convenient. It allows both for iterating back / forward one by one, as well as absolute addressing.

Why is it that way? You could search through the vim_dev mailing list archives for messages when this feature had been proposed / a patch submitted, or ask there if anyone remembers the background. (Note that there are many other features with less-than-optimal interfaces; it's a volunteer project with a single bottleneck BDFL at the top, and the worse is better mentality certainly applies here.)

To perform relative tab navigation in forward direction, you can use:

:execute 'tabnext' tabpagenr() + N

You can easily define a custom command or mapping if you find this useful.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.