On 2022-06-03, Clément Bœsch wrote:
>> 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.
>>> 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?
- Some Vim help files (filetype help)
- 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.
That would be nice. I don't know whether it could be overridden
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
--
--
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/20220603185845.GC23469%40phoenix.
