On 2022-06-03, Clément Bœsch wrote: > 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
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. > 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. > 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 <filetype>_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. 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 > neovim/neovim# 18843. At the time of writing, a global option > solution seems rejected there while the other approaches are still > considered. There are reasons why they're still considering various approaches-- there probably isn't one that's going to make everyone happy. Regards, Gary -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20220603161355.GB23469%40phoenix.
