gruvbox-community / gruvbox

Retro groove color scheme for Vim - community maintained edition
MIT License
801 stars 62 forks source link

Neovim 8: add new highlight groups #188

Closed undu closed 12 months ago

undu commented 1 year ago

These are the uncontroversial ones, with a clear correspondence with the ones already defined in gruvbox (see https://github.com/gruvbox-community/gruvbox/issues/154#issuecomment-1115559619)

The controversial ones have been added as comments so that they're easy to copy-pasted and overriden to the personal config

rbong commented 12 months ago

Thanks so much for this, sorry it fell off of my radar.

I found a few of the highlight groups you found controversial to actually map to existing groups in a pretty straightforward way on close inspection.

I also removed GruvboxWhite as we have GruvboxFg3, changed TypeDef to Typedef, made Bracket/Delimiter default groups, removed the superceded TreeSitter fix, and fixed a duplicate group.

Please let me know if there are any issues.

rbong commented 12 months ago

Two more things:

I've released v3.0.0 after these changes as this is a pretty major change and there hasn't been a release since 2020.

I've invited you @undu to the gruvbox-community organization for your contributions to treesitter and LSP groups, we always need more people to make sure there are plenty of people to look after the community edition.

undu commented 11 months ago

Thanks! everything is looking good as far as I can see, thanks for taking care of of gruvbox, I'll try to do the same :)

rbong commented 11 months ago

Thank you @undu

I'm changing @variable to Identifier because I think that's closer to how most languages handle it - although some languages do have white variables right now, many also have white identifiers of other types. It doesn't make sense visually to have white variables, then have arguments, properties, etc. as identifiers, because I've noticed that some colors can switch from blue to white depending on how the variable is used.

I considered making brackets white or orange again but having a separate color for them distinct from special symbols or identifiers is useful in many languages and that's how they're configured already. Why not have it for all languages?

A more classic look for many languages might be:

autocmd ColorScheme gruvbox hi! link Identifier GruvboxFg1
autocmd ColorScheme gruvbox hi! link Bracket Special

It might be a good idea to go back and revisit how some languages are set up. Why do we even have so many languages that have colors that aren't linked to everything? Why are they so different? See #193

Gruvbox has been very inconsistent on this but of course Treesitter is our chance to introduce some consistency. Of course languages that actually have a reason to have distinct colors should also have their colors ported to TreeSitter, but I honestly believe it's probably just dealing with these exact same issues and probably this solution for distinguishing between identifiers, brackets, and special symbols solves most problems.

rbong commented 11 months ago

Sorry, that really looked wrong. It's now:

This is close to what it was before with not as many color conflicts.

undu commented 11 months ago

I'll have to try the changes, I've commented on some changes that I are worth considering changing.

On some decisions around variables and delimiters I'll have to try before, but I liked a few specific things from before so I'll override the settings, not sure how popular these changes will be ;)

rbong commented 11 months ago

Please feel free to share your settings, I would love a second opinion on the colors. I am hoping that any issues with the new colors is offset by the customizability of using the generic syntax highlighting groups more, I am almost done porting every language to using these groups instead of direct links to colors to avoid any new conflicts.