[vim/vim] EOL whitespace highlight (Issue #10516)
Clément Bœsch
If we want to highlight EOL whitespaces, we currently have to rely on magic incantations such as:
highlight WhitespaceEOL ctermbg=red match WhitespaceEOL /\\\@<!\s\+\%#\@<!$/ augroup winenter_whitespaceeol autocmd! autocmd WinEnter * match WhiteSpaceEOL /\\\@<!\s\+\%#\@<!$/ augroup END
The list option kind of helps but it's often not really visible and it doesn't seem there is any way of customizing the listchars color.
In C, there is c_space_errors setting that helps but it's C only so it has a very limited use.
I'm not sure about which solution to pick between adding the ability to set color codes in listchars, adding a global option or something else. But the quoted blob is not exactly a solution for most users.
As requested by the neovim project, this issue is a duplicate of neovim/neovim#18843. At the time of writing, a global option solution seems rejected there while the other approaches are still considered.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
The list option kind of helps but it's often not really visible and it doesn't seem there is any way of customizing the listchars color.
I guess than you should tweak your colorscheme setting so that it is easily visible.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Clément Bœsch
The list option kind of helps but it's often not really visible and it doesn't seem there is any way of customizing the listchars color.
I guess than you should tweak your colorscheme setting so that it is easily visible.
But that's going to highlight all listchars, not just the lcs-eol isn't it? The goal is to make an emphasis on trailing whitespaces because those are considered errors.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Martin Tournoij
Note that set list isn't an exact equivalent of your regexp; the reason it's somewhat complex is that it excludes trailing whitespace when you're still typing things, so that typing x =<Space> doesn't highlight it as an "error" before you have a chance to type the value (which would be annoying).
But with set list listchars=trail:X the trailing space is immediately highlighted, and would behave identical to the much simpler match WhitespaceEOL /\s+$/.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Clément Bœsch
Note that
set listisn't an exact equivalent of your regexp; the reason it's somewhat complex is that it excludes trailing whitespace when you're still typing things, so that typingx =<Space>doesn't highlight it as an "error" before you have a chance to type the value (which would be annoying).But with
set list listchars=trail:Xthe trailing space is immediately highlighted, and would behave identical to the much simplermatch WhitespaceEOL /\s+$/.
/\s\+$/ but yes you are correct. The regex also handles the \ escape character as well.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Gary Johnson
> If we want to highlight EOL whitespaces, we currently have to rely
> on magic incantations such as:
>
> highlight WhitespaceEOL ctermbg=red
> match WhitespaceEOL /\\\@<!\s\+\%#\@<!$/
> augroup winenter_whitespaceeol
> autocmd!
> autocmd WinEnter * match WhiteSpaceEOL /\\\@<!\s\+\%#\@<!$/
> augroup END
solution.
I tried such a solution for a while, and also tried Dan Church's
shitespace.vim plugin, but neither did quite what I wanted, so
I wrote my own plugin so that I could enable/disable such
highlighting automatically per file type and per project and
manually per window.
The "right" solution varies from user to user. Vim provides tools
that allow each user to have the behavior they want.
> In C, there is c_space_errors setting that helps but it's C only
> so it has a very limited use.
for c_space_errors, you'll find it used by 8 file types. Further,
grepping for just _space_errors will show that technique, with
prefixes other than "c", used by another 13 file types.
> I'm not sure about which solution to pick between adding the
> ability to set color codes in listchars, adding a global option or
> something else. But the quoted blob is not exactly a solution for
> most users.
commonly, though not widely, used. If your favored language doesn't
have that, propose or submit a patch.
It's easy to visualize having Vim's highlighting "just work" for
you, but it's trickier to achieve. From my experience, you would
not be happy with a global setting; there are too many files whose
EOL spaces you'd like to ignore while not ignoring those in the
file(s) you're working on.
> As requested by the neovim project, this issue is a duplicate of
> considered.
there probably isn't one that's going to make everyone happy.
Regards,
Gary
vim-dev ML
> on magic incantations such as:
>
> highlight WhitespaceEOL ctermbg=red
> match WhitespaceEOL /\\\@<!\s\+\%#\@<!$/
> augroup winenter_whitespaceeol
> autocmd!
> autocmd WinEnter * match WhiteSpaceEOL /\\\@<!\s\+\%#\@<!$/
> augroup END
solution.
I tried such a solution for a while, and also tried Dan Church's
shitespace.vim plugin, but neither did quite what I wanted, so
I wrote my own plugin so that I could enable/disable such
highlighting automatically per file type and per project and
manually per window.
The "right" solution varies from user to user. Vim provides tools
that allow each user to have the behavior they want.
> so it has a very limited use.
for c_space_errors, you'll find it used by 8 file types. Further,
grepping for just _space_errors will show that technique, with
prefixes other than "c", used by another 13 file types.
> ability to set color codes in listchars, adding a global option or
> something else. But the quoted blob is not exactly a solution for
> most users.
commonly, though not widely, used. If your favored language doesn't
have that, propose or submit a patch.
It's easy to visualize having Vim's highlighting "just work" for
you, but it's trickier to achieve. From my experience, you would
not be happy with a global setting; there are too many files whose
EOL spaces you'd like to ignore while not ignoring those in the
file(s) you're working on.
> solution seems rejected there while the other approaches are still
> considered.
there probably isn't one that's going to make everyone happy.
Regards,
Gary
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Clément Bœsch
One person's magic incantation is another person's flexible
solution.I tried such a solution for a while, and also tried Dan Church's
shitespace.vim plugin, but neither did quite what I wanted, so
I wrote my own plugin so that I could enable/disable such
highlighting automatically per file type and per project and
manually per window.The "right" solution varies from user to user. Vim provides tools
that allow each user to have the behavior they want.
I wouldn't explain the need for users to write such vimscript plugins to be
driven by the enjoyment of the flexibility of vim. I'd rather say that many
people are desperate and ends up writing and copy/pasting abominations from the
web to circumvent the limitations of their editor.
In C, there is c_space_errors setting that helps but it's C only
so it has a very limited use.
c_space_errors is not just for C. If you grep $VIMRUNTIME/syntax
for c_space_errors, you'll find it used by 8 file types. Further,
grepping for just _space_errors will show that technique, with
prefixes other than "c", used by another 13 file types.
Ah, my mistake I wasn't aware (to my defense the name is quite confusing).
I'm not sure about which solution to pick between adding the
ability to set color codes in listchars, adding a global option or
something else. But the quoted blob is not exactly a solution for
most users.
The _space_errors solution seems to be the easiest and is
commonly, though not widely, used. If your favored language doesn't
have that, propose or submit a patch.
I never came across a filetype where I didn't want the trailing whitespace to
be shown as error, including a lot of unrecognized file types from vim, as well
as a simple scratchpad. I'm not saying it doesn't exist, but it feels like the
exception. Do you have an example?
It's easy to visualize having Vim's highlighting "just work" for
you, but it's trickier to achieve. From my experience, you would
not be happy with a global setting; there are too many files whose
EOL spaces you'd like to ignore while not ignoring those in the
file(s) you're working on.
Oh I'm not insisting on having a global setting. I was actually pretty seduced
by the proposition from @bfredl to add a dedicated highlight. Taking into
account what you said about language specificities, it brings the question
whether this default highlight could be overwritten by some syntax file, where
the trailing whitespace could be considered normal.
Regards,
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Martin Tournoij
I'd rather say that many people are desperate and ends up writing and copy/pasting abominations from the web to circumvent the limitations of their editor.
Are there "many" people who want this? I can't recall ever seeing this come up before.
What I do see come up much more often is wanting to trim trailing whitespace; I have a little :TrimWhitespace command in my vimrc too as I sometimes end up with excessive trailing whitespace after some :s command or whatnot. But that's something different from "highlight trailing spaces as an error".
I never came across a filetype where I didn't want the trailing whitespace to be shown as error
The most common I know of are Markdown files, where two trailing spaces indicate a hard enter; emails, where --<Space> is used to indicate the start of a signature; and some "raw code blocks" such as:
repl := strings.NewReplacer("\t", "", "\n", "")
varname := `
foo
bar
`
fmt.Println(repl.Replace(varname))
That will become foo bar with the trailing space, or foobar without one.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Clément Bœsch
I'd rather say that many people are desperate and ends up writing and copy/pasting abominations from the web to circumvent the limitations of their editor.
Are there "many" people who want this? I can't recall ever seeing this come up before.
This question has been raised 11 years ago and there seems to be quite some activity: https://stackoverflow.com/questions/4617059/showing-trailing-spaces-in-vim
There is even a dedicated wiki page full of hacks like the one I proposed: https://vim.fandom.com/wiki/Highlight_unwanted_spaces
You may also have seen that git has the feature builtin and enabled by default (they appear in red):
--check
Warn if changes introduce conflict markers or whitespace errors. What are
considered whitespace errors is controlled by core.whitespace
configuration. By default, trailing whitespaces (including lines that
consist solely of whitespaces) and a space character that is immediately
followed by a tab character inside the initial indent of the line are
considered whitespace errors. Exits with non-zero status if problems are
found. Not compatible with --exit-code.
So well, yeah actually that's a requested feature.
What I do see come up much more often is wanting to trim trailing whitespace; I have a little
:TrimWhitespacecommand in my vimrc too as I sometimes end up with excessive trailing whitespace after some:scommand or whatnot. But that's something different from "highlight trailing spaces as an error".
Yes I also have that. But in order to know we have to trim the whitespaces, we need to know if they are present in the first place.
I never came across a filetype where I didn't want the trailing whitespace to be shown as error
The most common I know of are Markdown files, where two trailing spaces indicate a hard enter
Interesting, I wasn't aware of that. I don't see anything in the CommonMark specification though. All the trailing whitespaces I came across in markdown files were mistakes.
emails, where
--<Space>is used to indicate the start of a signature
Ah yeah I remember this one.
and some "raw code blocks" such as:
repl := strings.NewReplacer("\t", "", "\n", "") varname := ` foo bar ` fmt.Println(repl.Replace(varname))That will become
foo barwith the trailing space, orfoobarwithout one.
Interesting. Still, wouldn't it make sense to make exception for those instead of the other way around? In the vast majority of cases, the trailing whitespaces are present by mistake.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Martin Tournoij
I don't see anything in the CommonMark specification though.
https://spec.commonmark.org/0.30/#hard-line-breaks
It's been a feature since the original Perl Markdown from Gruber AFAIK.
I used to use it, but switched to just writing <br> because of all the people with "automatically remove all trailing whitespace" in their editors. I'm usually also careful to write code like email signatures or things like the code example in a way that it doesn't really have trailing whitespace (arguably, that's a better way to write it in the first place, since it's so hard to see).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Gary Johnson
>> solution.
>>
>> I tried such a solution for a while, and also tried Dan Church's
>> shitespace.vim plugin, but neither did quite what I wanted, so
>> I wrote my own plugin so that I could enable/disable such
>> highlighting automatically per file type and per project and
>> manually per window.
>>
>> The "right" solution varies from user to user. Vim provides tools
>> that allow each user to have the behavior they want.
>
> I wouldn't explain the need for users to write such vimscript plugins to be
> driven by the enjoyment of the flexibility of vim. I'd rather say that many
> people are desperate and ends up writing and copy/pasting abominations from the
> web to circumvent the limitations of their editor.
that's going to please everyone. Witness the controversy
surrounding the defaults.vim file.
>>> I'm not sure about which solution to pick between adding the
>>> ability to set color codes in listchars, adding a global option or
>>> something else. But the quoted blob is not exactly a solution for
>>> most users.
>>
>> The _space_errors solution seems to be the easiest and is
>> commonly, though not widely, used. If your favored language doesn't
>> have that, propose or submit a patch.
>
> I never came across a filetype where I didn't want the trailing whitespace to
> be shown as error, including a lot of unrecognized file types from vim, as well
> as a simple scratchpad. I'm not saying it doesn't exist, but it feels like the
> exception. Do you have an example?
- The calendar from the calendar.vim plugin (filetype calendar)
- Some buffers created by the Fugitive plugin (filetype git)
- Some quickfix error lists (filetype qf)
I'm not going to fix those and the highlighting I use is jarring, so
I disable the trailing whitespace highlighting for those filetypes.
>> It's easy to visualize having Vim's highlighting "just work" for
>> you, but it's trickier to achieve. From my experience, you would
>> not be happy with a global setting; there are too many files whose
>> EOL spaces you'd like to ignore while not ignoring those in the
>> file(s) you're working on.
>
> Oh I'm not insisting on having a global setting. I was actually pretty seduced
> by the proposition from @bfredl to add a dedicated highlight. Taking into
> account what you said about language specificities, it brings the question
> whether this default highlight could be overwritten by some syntax file, where
> the trailing whitespace could be considered normal.
with filetype resolution.
I've actually been using matchadd() and matchdelete() to control
that highlighting because I also want those spaces highlighted in
files for which I don't want syntax highlighting enabled.
Regards,
Gary
vim-dev ML
>> One person's magic incantation is another person's flexible
>> solution.
>>
>> I tried such a solution for a while, and also tried Dan Church's
>> shitespace.vim plugin, but neither did quite what I wanted, so
>> I wrote my own plugin so that I could enable/disable such
>> highlighting automatically per file type and per project and
>> manually per window.
>>
>> The "right" solution varies from user to user. Vim provides tools
>> that allow each user to have the behavior they want.
>
> I wouldn't explain the need for users to write such vimscript plugins to be
> driven by the enjoyment of the flexibility of vim. I'd rather say that many
> people are desperate and ends up writing and copy/pasting abominations from the
> web to circumvent the limitations of their editor.
Yeah, but it's difficult to find an out-of-the-box configuration
that's going to please everyone. Witness the controversy
surrounding the defaults.vim file.
>>> ability to set color codes in listchars, adding a global option or
>>> something else. But the quoted blob is not exactly a solution for
>>> most users.
>>
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.