Fix for:
https://vi.stackexchange.com/questions/39755/how-to-make-lead-override-trail-in-listchars

The diff mainly shows lines that have been indented differently. Please use a 'shiftwidth' value of four.
Once that is fixed we can better see what you are actually changing.
This also deserves a change in the help for 'listchars' and a test case.

Why is it preferred to present them as leading?

https://vi.stackexchange.com/questions/39755/how-to-make-lead-override-trail-in-listchars

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 elseif conditions.

However, if we change this now, I am sure other people will complain :(
So this should be made configurable. But just adding yet another option for this minor change is also not nice...

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.

Ah, I guess my hint was useful :)

Yup, thanks @chrisbra :)

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.

That's a cool trick with the w=1 query param @chrisbra. For future observers' reference, I found a source explaining this feature of Github to ignore whitespace discrepancies in diffs here.

Why is it preferred to present them as leading?

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 :)
In the docs from :help listchars, multiple of the options "override" each other. There is no configurability, but the precedence/overriding behavior makes intuitive sense.

1. I don't think this PR works at all. You didn't change line 1522.
2. One may set "trail" in 'listchars' to a character that is easy to spot, so they can remove them. Hardly anyone wants to remove leading spaces.

1. Maybe it is presumptive of me to assume that lead should override - since this precedence is recognized in more than one place (line 1522 as you said), was there originally a deeper reason why trail is preferred to lead?

Hardly anyone wants to remove leading spaces.

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.

The commit e85b23b should be removed. The commit message says:

Fix lines with mixed tab and space to only use tabs

but Vim's source code intentionally uses mixed tab and space.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 73.02%. Comparing base (62a6923) to head (ba41868).
Report is 2835 commits behind head on master.

❗ There is a different number of reports uploaded between BASE (62a6923) and HEAD (ba41868). Click for more details.

HEAD has 4 uploads less than BASE

Flag	BASE (62a6923)	HEAD (ba41868)
huge-gcc-unittests	1	0
linux	4	2
huge-clang-none	1	0

@@            Coverage Diff             @@
##           master   #11876       /-   ##
==========================================
- Coverage   81.88%   73.02%   -8.87%     
==========================================
  Files         164      160       -4     
  Lines      193236   188913    -4323     
  Branches    43790    43179     -611     
==========================================
- Hits       158236   137956   -20280     
- Misses      22182    38720    16538     
  Partials    12818    12237     -581     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Vim's source code intentionally uses mixed tab and space

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?
It could be called "empty" perhaps. That also makes it backwards compatible.

let's not do this.