ap / vim-css-color

Preview colours in source code while editing
http://www.vim.org/scripts/script.php?script_id=5056
MIT License
1.77k stars 78 forks source link

update i3config for vim 8.2 #167

Closed thiagowfx closed 2 years ago

thiagowfx commented 2 years ago

Vim 8.2 ships with a i3config.vim file out-of-the-box1. The relevant highlight is i3ConfigColor2.

Fixes https://github.com/ap/vim-css-color/issues/94

thiagowfx commented 2 years ago

@ap FYI: I chose to get rid of the other files to simplify future maintenance. That said, if you prefer to keep them for compatibility reasons I am fine with reverting the deletions. I would advise against it though.

ap commented 2 years ago

I would advise against it though.

Why?

ap commented 2 years ago

FWIW, this isn’t just broken in Vim 8.2, it’s broken with the original plugin too. Commit mboughaba/i3config.vim@dff3b177ebaf6aae35591cd4c9c734fff9ed7145 changed all the syntax group names.

thiagowfx commented 2 years ago

Why?

Arguably:

The only reason I see to keep the other file is if you want to support folks that may be running older versions of vim that don't yet ship the i3config.

As mentioned, I am totally fine to follow whatever you decide, the above is just my rationale/advice. :)

ap commented 2 years ago

simplifies future project maintenance, relying less on custom plug-ins

Well the plugin doesn’t rely on them so much as support them… unless the supported plugins change all the time, “maintenance” consists of just keeping the files. I believe the change within i3config.vim that broke CSS Color’s support for it is the first time I’ve had this kind of thing happen at all.

if there's an upstream version, there's little point supporting the custom ones

For new users of the plugin, yes, but what about people already running it in existing configurations?

I don’t believe in forcing people to get with the program either; in fact I think breaking things on purpose to push them into that has the opposite effect, making people hesitant to upgrade – because now every upgrade is a cascade of new fails that have to be fixed. And there are always more useful investments of time than “my gain at the end of all this effort is that I can use all the stuff I could already use before I upgraded”. (Sometimes, upgrades do deliver some benefit so overwhelming great and universal that it justifies this sort of expenditure. But I would argue that this is mostly a maintainer fantasy that only very rarely actually happens, and that in practice, most upgrades are a wash and occasionally there is some mild benefit.)

The community would benefit more by upkeeping the upstream one now

Well yeah, but unless there’s some drastic fundamental change to it, upkeep in CSS Color tends to amount to “keep the file around”.

Generally, the inclusion of a plugin for some filetype into Vim tends to mean that competing plugins lose relevance from then on. Logically that seems to me to to make them even more unlikely to make changes that would require upkeep in CSS Color – though I have no factual basis for that claim since it has basically never happened before under any circumstance anyway.

Moreover, the end of the road for competing plugins by definition implies people getting with the program, all by themselves – just over time, rather than all at once.

ap commented 2 years ago

Anyway, the important thing is that i3config.vim changed and CSS Color needed a fix to its support – thank you for that.