Prefer lead whitespace character over trail whitespace character #11876
Conversation
Lines that consist of only spaces treat the spaces as trailing characters as opposed to leading characters. This is technically an ambiguous edgecase because the spaces are both leading AND trailing. However, presenting the characters as leading is preferred. https://vi.stackexchange.com/q/39755/45006
|
The diff mainly shows lines that have been indented differently. Please use a 'shiftwidth' value of four. |
|
Why is it preferred to present them as leading? |
Ah, I guess my hint was useful :) This diff here makes it more clear: https://github.com/vim/vim/pull/11876/files?diff=unified&w=1 It basically just switches the However, if we change this now, I am sure other people will complain :( So perhaps it makes sense to enhance the 'listchars' option to somehow allow to configure priorities for 'lead'/'trail'? I vaguely remember this being discussed when the 'lead' or 'trail' option was added to 'listchars', but cannot find references. |
Yup, thanks @chrisbra :)
I also delineated into two separate commits to make it easier to view. The more important commit is here. That's a cool trick with the
Whenever one starts typing at the end of an indented line, there is a sudden conversion of all whitespace characters from trailing form to leading form. IMO it would be preferable as default behavior to have them be leading form the whole time instead of this sudden conversion from trailing form to leading form. What is lost by doing this? Well if we follow the convention of my pull request, then any scenario where you start typing at the beginning of a line that already has indentation will convert leading form into trailing form. But it is almost never the case that you start typing at the beginning of a line before the whitespace. Having precedence between whitespace characters is not without... precedent :) |
|
I agree! They are just not being recognized as leading spaces until you type another character after. While you think about what to type on an indented line, you have trailing characters staring at you that you are tempted to delete. Typing a dummy character after the whitespace is the only remedy. |
|
> This diff here makes it more clear: https://github.com/vim/vim/pull/11876/files?diff=unified&w=1
I also delineated into two separate commits to make it easier to view. The more important commit is [here](dd432ad).
It's not just about viewing the diff, the indent is not right.
The "if" block has 4 spaces too much.
…--
Light travels faster than sound. This is why some people
appear bright until you hear them speak
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
|
The commit e85b23b should be removed. The commit message says:
but Vim's source code intentionally uses mixed tab and space. |
Codecov Report
@@ Coverage Diff @@
## master #11876 +/- ##
=======================================
Coverage 81.88% 81.89%
=======================================
Files 164 164
Lines 193236 193236
Branches 43790 43790
=======================================
+ Hits 158236 158251 +15
+ Misses 22182 22170 -12
+ Partials 12818 12815 -3
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
I reverted to using mixed tabs and spaces. I am not sure how to address comments from @zeertzjq about the potential for the convention (i.e. trail overrides lead) to be assumed elsewhere in the code. |
|
I have doubts whether this is an improvement. For me both trailing spaces after text and a line with just spaces are characters that should not be there. Leading spaces are different. Therefore using "trail" for spaces in a line without text makes sense to me. If some users don't like this, how about adding another character for spaces in a line without any text? |
See description in commit message.