Thanks a lot.

• Please add Closes #3670 in the commit message detail.
  • Also consider https://github.com/neovim/neovim/blob/master/CONTRIBUTING.md#commit-guidelines
• The tests are showing 3 errors (search for the string "[ ERROR ]" to see the specific failures), but it appears that they simply need to be updated to meet the new expectations (please verify).
  • If that's the case, then we may not need a new test written for this PR. Otherwise a new test would be great.

Please leave a comment if you update the PR, so we don't miss it.

I fixed these 3 test errors, in which the listchars should override visual mode highlight.

I found that there is not lua test coverage on cursorline, so I am not sure whether I need to add additional tests for it.

Any suggestions?

@zhou13 It is always better to add test for the functionality that is not tested then not to add it. Neither Neovim complete test suite nor old Vim functional tests cover present functionality completely. But in addition to this Vim does not have framework for testing visual features, only having a few functions that may sometimes help, but are not as convenient.

I added two tests for cursorline/listchars and I fixed the lint warning.

I like this improvement, but there's inconsistency:

• visual-selection uses listchars-highlight for: eol tab trail extends
• visual-selection does not use listchars-highlight for: space precedes nbsp

It's arguable that visual-selection should use listchars-highlight for precedes/extends, but OTOH it departs from Vim and it makes it unclear where the selection starts and ends (which is why Vim behaves this way). So let's keep the Vim behavior for visual-selection.

@justinmk Hi justinmk, thanks for pointing out the inconsistency problem in visual selection. IMO, I think the "correct" behavior should be

• visual-selection should listchars-highlight for (different from VIM): eol tab trail nbsp space
• visual-selection should not use listchars-highlight for (same as VIM): extends precedes

This is because the former listchar represents a real character and the latter represents the continuity of a line. For the former one, the benefit is that now I can distinguish between <tab> and > when the I have listchar=tab:>\. I think the compatibility with vim is not so important if it brings more intuitive visual effect. Though I should fix the problem to make the listchars-highlight for 'space'. What's you opinion on this?

Also, I observed that 'extends' does not use the listchars-highlight in visual selection.

This is because the former listchar represents a real character and the latter represents the continuity of a line.

Yeah, but the problem is that any of those chars may exist at the start/end of a line, thus causing confusion.

I think the compatibility with vim is not so important if it brings more intuitive visual effect. Though I should fix the problem to make the listchars-highlight for 'space'. What's you opinion on this?

I'm not much worried about Vim-compat here, but I am very worried about making a change that is not a net improvement. In other words, if we make a change that has some pros and cons, and we choose the inverse of those pros and cons, we didn't really gain a net improvement. And I have a feeling we'll get lots of complaints about this and won't be able to defend it.

Yeah, but the problem is that any of those chars may exist at the start/end of a line, thus causing confusion.

Could you make an example to explain why it will cause the confusion in visual mode?

Could you make an example to explain why it will cause the confusion in visual mode?

Where - is the listchars space glyph:

foo bar ---

If the visual-selection bg color appears behind the --- then there won't be confusion. For extends it did not appear. I assumed it wouldn't appear for the others as well, but I realize now that's not the case.

TBH even highlighting extends and precedes with visual-selection bg seems wrong to me: they should be treated as meta-glyphs which are not part of the text (like the window separator line). So let's listchars-highlight them as well, and see if anyone complains (and then ignore them).

The default behavior of vim won't highlight extends and precedes with visual-selection bg, so I think we can just keep these behavior. But we should highlight eol tab trail nbsp space in visual selection using listchar. If you do not specify guibg and ctermbg for hl-SpecialKey and hl-NonText repespectively, which normally is the case, then it will use the normal visual highlight for the selection of these glyphs.

This is the current effect after this patch:
http://imgur.com/Ly1VmzT

So I think the only thing needs to be fixed is the highlight space listchar under visual selection.

So I think the only thing needs to be fixed is the highlight space listchar under visual selection.

Also nbsp, if I'm not mistaken.

I think I fixed all the known issues. Please review.

Merged after rebase.