Re: Feature Request: A special value for softtabstop that makes it equal to tabstop

[Christian Brabandt]

Hi So8res!

On Di, 02 Okt 2012, So8res wrote:

> Recently a patch went in such that if shiftwidth is zero then the value of tabstop is used:
>
> https://groups.google.com/forum/?fromgroups=#!searchin/vim_dev/shiftwidth=0/vim_dev/5Pq0B7dXGGA
>
> I like that feature a lot.
>
> It would be very nice to have a similar feature for softtabstop. Unfortunately, setting softtabstop=0 disables the softtabstop feature, so 0 might not work here. I propose either:
>
> * Change softtabstop so that 0 sets it equal to tabstop and a negative number turns it of
> * Make it so 0 turns it off and a negative number makes it equal to tabstop
>
> Justification: To quote from the tabstop help,
>
> There are four main ways to use tabs in Vim:
> 1. Always keep 'tabstop' at 8, set 'softtabstop' and 'shiftwidth' to 4
> (or 3 or whatever you prefer) and use 'noexpandtab'. Then Vim
> will use a mix of tabs and spaces, but typing <Tab> and <BS> will
> behave like a tab appears every 4 (or 3) characters.
> 2. Set 'tabstop' and 'shiftwidth' to whatever you prefer and use
> 'expandtab'. This way you will always insert spaces. The
> formatting will never be messed up when 'tabstop' is changed.
> 3. Set 'tabstop' and 'shiftwidth' to whatever you prefer and use a
> |modeline| to set these values when editing the file again. Only
> works when using Vim to edit the file.
> 4. Always set 'tabstop' and 'shiftwidth' to the same value, and
> 'noexpandtab'. This should then work (for initial indents only)
> for any tabstop setting that people use. It might be nice to have
> tabs after the first non-blank inserted as spaces if you do this
> though. Otherwise aligned comments will be wrong when 'tabstop' is
> changed.
>
>
> I'm a big proponent of #4. #1 mixes tabs and spaces at the top level which I find abhorrent. #2 removes the reader's ability to adjust the tabstop to their comfort level and have the code comply. #3 requires modelines don't work well for people using other editors and can have security concerns.
>
> If you use #4 then it's helpful to change <tab> (as suggested) to insert spaces after the first non-blank. At this point you pretty much always want tabstop, shiftwidth, and softtabstop to *always* be equal to each other. It gets annoying to have to "set ts=N sw=N sts=N" or whatever when you want to change the width of tabs to N.
>
> The above mentioned patch allows you to "set sw=0" once and then you need only "set ts=N sts=N" when you're changing your indent level, but that's still repetitive. I would love a patch that allows me to "set sw=0 sts=0" or something in my vimrc and then only ever touch tabstop thereafter.

Could you try the attached patch? (use sts=-1 to set it to the 'ts' value)

Mit freundlichen Gr��en
Christian

[Bram Moolenaar]

What is the point? When you set 'sts' to zero it already means that a tab
counts for 'tabstop' and a hard tab will be inserted.

It might make more sense to have a negative 'sts' value mean that
'shiftwidth' is used.


--
If an elephant is left tied to a parking meter, the parking fee has to be paid
just as it would for a vehicle.
[real standing law in Florida, United States of America]

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Milan Vancura]

Hi Bram.

> It might make more sense to have a negative 'sts' value mean that
> 'shiftwidth' is used.

Yes, this is what I do for years: sw and sts set to the same value (and to try
to not forget to change the second when changing the first). It would be a
pretty enhancement if sts followed sw value automatically.

Milan Van�ura

[So8res]

Works like a charm, Christian.

Bram, I'd love to have a negative sts mean that it's the same as sw. The reason I suggested a zero value is for consistency, in that setting sw=0 means use the sts value. I'd recommend allowing sw to be negative if we go ahead with this.

Attached is Christian's diff modified so that sts falls back to sw instead of ts.

[So8res]

Typo: setting sw=0 means use the tabstop value. True consistency would have this change accompanied by one which has sw=0 'turns sw off' and sw=-1 'uses the ts value'. (Though I can't imagine what turning sw off means aside from using the tabstop value, so I think it would be fine to just allow sw to be negative.)

Below is a patch which allows such behavior.

[So8res]

The above patch has a typo! Oops. I'd love to see this feature go in when the sw=0 indent fixes go in, because then we can just "set ts=8 sw=0 sts=-1" and use tabstop alone to adjust indent width. The second patch (corrected below) makes it so sw can also be negative (which means it falls back to tabstop) just for consistency with sts. I'm not sure if it's the right thing to do but it might be.

[Andy Wokula]

Er, again, what's the deal with sts=-1 ?
It's not needed.
So is sw=-1 (not needed, for consistency).

--
Andy

[So8res]

> Er, again, what's the deal with sts=-1 ?

sts=-1 would mean that sts takes on the same value as the shiftwidth.

This means you can change your shiftwidth and have the softtabstop change automatically. I (and I imagine most users with sts on) want the softtabstop to be one shiftwidth wide, but I often forget to update it.

The most common use case is deleting multiple spaces at a time. Imagine &sw=4 and &sts=4 and you have a file with 'expand' tab. You 'set sw=8'. Now when your cursor is sitting behind 16 spaces and you hit backspace you expect 8 spaces to be deleted, but only 4 are deleted because you forgot to update 'sts'. This is incredibly annoying.

> So is sw=-1 (not needed, for consistency).

sw=0 has a similar effect to sts=-1, i.e. sw=0 makes sw take on the same value as tabstop. It's a bit strange to have one start falling back on the '-1' value and the other on the '0' value, which is why I put the second patch up; it makes sw behave a little more consistently with sts. I'm not sure it's a good idea, but it's something to think about.

By the way, this version fixes a documentation error in the above patch:

[Andy Wokula]

There is another option, what about
ts=8
sts=4
sw=0
with effective shiftwidth = 4? I think 'shiftwidth' has a stronger
connection to 'softtabstop' than to 'tabstop' ... Is it useful to get
an effective shiftwidth of 8 in this case?

If not then negative values for sw / sts should be avoided.

But you have to change 'softtabstop' instead of 'shiftwidth'.

--
Andy

[So8res]

That's certainly a possibility, though then I'd want "sts=-1" to make "sts" fall back to the "tabstop" value or we still have the problem of setting the same thing in two places. The original patch actually had sts falling back to tabstop, but Bram thought it was better to have sts fall back to shiftwidth.

[Gary Johnson]

I know we want to avoid option bloat, but I really hate "special"
values, especially ones as non-obvious as these.

How about instead a new boolean option, 'tabbind'? When off,
'shiftwidth', 'tabstop' and 'softtabstop' are all independent. When
on, all those values are set to that of the last one set.

For example, if 'tabbind' is on when the user sets 'tabstop', both
'shiftwidth' and 'softtabstop' are also set to the new value of
'tabstop'. The user doesn't have to remember what "-1" means or
which option needs to be set last to affect the others.

Regards,
Gary

[Ben Fritz]

On Tuesday, October 16, 2012 7:04:49 PM UTC-5, Gary Johnson wrote:
> I know we want to avoid option bloat, but I really hate "special"
> values, especially ones as non-obvious as these.
>
> How about instead a new boolean option, 'tabbind'? When off,
> 'shiftwidth', 'tabstop' and 'softtabstop' are all independent. When
> on, all those values are set to that of the last one set.
>

I think having too many options is better than having too few with special overloaded behaviors. That is just my preference though.

> For example, if 'tabbind' is on when the user sets 'tabstop', both
> 'shiftwidth' and 'softtabstop' are also set to the new value of
> 'tabstop'. The user doesn't have to remember what "-1" means or
> which option needs to be set last to affect the others.
>

I like this idea very much.

[Christian Brabandt]

I tend to not agree. I don't like having yet another option plus once
we have this option, someone wants this to be local to buffer or someone
want to have 'sw' follow 'ts' but not 'sts'.

I think it is easier, if we just document the special behaviour of
using 0 or -1 or whatever value we agree about.

Users that care to customize, can read about the special values in the
documentation, which they have to do anyhow. If they don't care, they use
whatever their disro or filetype plugin provides and then it is no
problem, that the values are not obvious.

regards,
Christian

[Andy Wokula]

> Milan Vančura

This *is* supported:

:h 'smarttab
:set ts& sts& sw=4 sta

sts=0 and spaces/tabs in the indent part are inserted according to 'shiftwidth'.

--
Andy

[Andy Wokula]

Am 17.10.2012 02:28, schrieb Ben Fritz:
> On Tuesday, October 16, 2012 7:04:49 PM UTC-5, Gary Johnson wrote:
>> I know we want to avoid option bloat, but I really hate "special"
>> values, especially ones as non-obvious as these.
>>
>> How about instead a new boolean option, 'tabbind'? When off,
>> 'shiftwidth', 'tabstop' and 'softtabstop' are all independent. When
>> on, all those values are set to that of the last one set.
>
> I think having too many options is better than having too few with
> special overloaded behaviors. That is just my preference though.

Now you can change 'tabstop' via 'softtabstop' ... great, this is even
more black magic (just next to 'gdefault', 'remap', 'magic',
'edcompatible', etc.)

>> For example, if 'tabbind' is on when the user sets 'tabstop', both
>> 'shiftwidth' and 'softtabstop' are also set to the new value of
>> 'tabstop'. The user doesn't have to remember what "-1" means or
>> which option needs to be set last to affect the others.

With good luck, a value of -1 is not needed.

> I like this idea very much.

The user still cannot have ts=8 and sts+sw bound together
(without the 'smarttab' side effects).

--
Andy