Closed inkarkat closed 2 years ago
@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.
@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.)
aware (and supportive) of EditorConfig
Thanks very much indeed! :tada:
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.)
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.
@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!
The
softtabstop
setting is meant to be used with a value that is different from thetabstop
setting (andtabstop
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 thetabstop
/ 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 totabstop
andshiftwidth
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 thetabstop
(andshiftwidth
) values. Suddenly,tabstop
is different thansofttabstop
, 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 positivesofttabstop
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 resetsofttabstop
to 0, to avoid the potential bad effects just mentioned. Users may have globally turnedsofttabstop
on, and that global value would then still be inherited into buffers under control of EditorConfig configurations.