Permit disabling softtabstop control, as softtabstop is a Vim-specific feature not supported by EditorConfig

[inkarkat]

The softtabstop setting is meant to be used with a value that is different from the tabstop setting (and tabstop typically then kept at the default 8), and then renders the indent first with hard tabs, filling remaining differences with spaces. Though this has some nice editing characteristics (no messing with tabstop values but still getting cursor progressing to certain columns), it is quite specific to Vim and hasn't caught on elsewhere. Therefore, the EditorConfig spec doesn't support this feature.

The existing implementation sets softtabstop to the tabstop / indent size, effectively turning off the feature completely. That is not wrong. However, Vim documents that the feature is turned off by a value of 0; a value equal to tabstop and shiftwidth effectively turns off the feature as well. The difference matters when hard tabs are configured and the user (maybe temporarily) manually adjusts the size of an indent by changing the tabstop (and shiftwidth) values. Suddenly, tabstop is different than softtabstop, and Vim starts inserting the mix of tabs and spaces that the softtabstop feature is about! Also, some plugins or statuslines may wrongly interpret the positive softtabstop value to indicate activation of the softtabstop feature, even though it's effectively off.

This change is related to #137; however, instead of dropping the modification of softtabstop altogether, I think it's better to reset softtabstop to 0, to avoid the potential bad effects just mentioned. Users may have globally turned softtabstop on, and that global value would then still be inherited into buffers under control of EditorConfig configurations.

[cxw42]

@inkarkat Great to hear from a wizard :) . Thanks for the PR! Just to confirm, sts=0 is independent of expandtab? I've always used et ts=N sts=N sw=N for N-space indent.

[inkarkat]

@cxw42 As a longtime Vim user, I've so far relied on local vimrc indent settings and my own IndentConsistencyCop plugin. I've been aware (and supportive) of EditorConfig for a long time though; now a colleague of mine has introduced EditorConfig at work, so I've started using it, too.

With enabled expandtab, enabling softtabstop makes even less sense, as the space-only indent can already be fully achieved by setting the desired tabstop and shiftwidth. In general, both tabstop option (for inserting tabs) and shiftwidth (for indenting commands) affect the amount of indent. If expandtab is on, that amount directly gets rendered into spaces. Else, if softtabstop is on and its value differs from tabstop, Vim does that strange combination of tabs followed by the remainder in spaces.

Your et ts=N sts=N sw=N works fine, and I like that you've specified all indent-related settings in there. I would prefer et ts=N sts=0 sw=N though, as it avoids the cornercase problems I've mentioned and better communicates that the softtabstop feature is disabled. Today you could even use et ts=N sts=0 sw=0, which has the benefit that a single setting (ts) controls the indenting entirely. (But very old Vim versions didn't support sw=0 yet.)

[cxw42]

Given two votes for removing the effect of sts, I think it's reasonable to make that an option.
However, this change affects the ergonomics of Vim for every file edited to which the plugin applies edit and for which indent_style = space. I think that, as a user, I would be very surprised if an update to EditorConfig changed how <BS> worked (instead of one indent level, a single space, when indent_style = space).

Would you please update this PR to keep the existing behaviour unless g:EditorConfig_sts_zero (or something like that) is set before plugin load? Adding that option will (I think) give you what you need without surprising existing users.

Changes I am requesting:

• Functional change here
• plugin/editorconfig.vim: if the global is unset, set it to 0
• doc/editorconfig.txt: document the option

Let me know your thoughts! Thanks very much!

[cxw42]

aware (and supportive) of EditorConfig

Thanks very much indeed! 🎉

[chreekat]

As the author of #137, I do not oppose this PR. ;)

It's still not the way I would write it, but that should not be a blocker.

(In short, I think -1 and 0 are both perfectly reasonable values for sts, and I wouldn't want EditorConfig to make that choice for me. I consider sts a UI feature, not an editing/filetype feature.)

[inkarkat]

Thanks @cxw42 for bringing up the issue with backspacing and space-indents! I've rarely used space-indenting, and almost forgot that 'softtabstop' needs to be enabled there.

Great that @chreekat approves and chimed in here as well; I hopefully have reworked my PR with a second commit to address your feedback as well.

---

I think there should be two separate plugin config options; g:EditorConfig_softtabstop_space and g:EditorConfig_softtabstop_tab, because of the importance of softtabstop in combination with 'expandtab'. The default value of 1 will keep the current behavior, 0 can disable 'softtabstop', and an empty List ([]) will prevent the plugin from touching that option at all.

I've written almost too much documentation for these options, but I think most users will be fine with the defaults and those who do have a desire to tweak this need a bit of explanation, as Vim itself carries a lot of historic baggage and hard-to-understand documentation with it there.

[cxw42]

@inkarkat Thanks very much! The updates seem reasonable to me. I tried out the new code locally and it appears to work as described in the documentation :) . Happy Vimming!