vim
feat: new colorscheme "lunaperche"
(GUI, 256, 16, 8) Minimal dual background colorscheme:
- Statement is bold
- Type is bold green
- Constant is red for light, yellow for dark
- Comment is blue
- PreProc is dark yellow
~Not all the default syntax groups are highlighted, thus some/many filetype syntaxes require additional setup.~
What do you mean by "Not all the default syntax groups are highlighted, thus some/many filetype syntaxes require additional setup."?
Well, it looks like only Identifier is not highlighted == has normal colors (which is by design).
And actually I expressed myself completely wrong in that sentence, what I really wanted to say is that for many syntaxes it might look not the way I like it to be due to chaotic usage of non-statement syntax for statements and vice versa. For these cases additional setup would be needed. (which is again, wrong, me as a colorscheme author would be adding them into colorscheme as soon as I meet them. No setup from the user is required)
The custom linking going on under the hood seems like it could go sideways very fast.
Custom elements used by plugins, semantics (granted, in some cases the default syntax files are clearly wrong), links to add or modify as the syntax files shipped with vim evolve over time, potential breakage if something in the highlighting backend is modified...
I'm also not crazy about shipping a "full-featured" colorscheme that doesn't highlight one of the major groups, but that's more a nitpick than anything.
I'm also not crazy about shipping a "full-featured" colorscheme that doesn't highlight one of the major groups, but that's more a nitpick than anything.
Identifier is abused so much I can't stand it, so no color for it is a "design decision".
And actually some of the built-ins do the same (elflord, ron for instance, plus zellner has identifier and type with the same color)
As for custom linking, I think this is fine as they do no harm even if some plugins would stop using it. But here we need a joint decision as I suspect new colorscheme authors would expect links to custom groups (I remember the quesition in the past and @romainl answered that while vim has link bug it is not welcomed, but it was fixed since then...)
some of the built-ins do the same (elflord, ron for instance, plus zellner has identifier and type with the same color)
These don't count :smile:
As for custom linking, I think this is fine as they do no harm even if some plugins would stop using it. But here we need a joint decision as I suspect new colorscheme authors would expect links to custom groups (I remember the quesition in the past and @romainl answered that while vim has link bug it is not welcomed, but it was fixed since then...)
That bug is/was my main concern. I wasn't able to trigger it when I wrote the previous post, but assumed I was just forgetting something. If it's been fixed, great, I'm just a bit worried about the long-term consequences. You know, one thing leads to another, and suddenly you're maintaining solarized :smile:
The contrast between Special and Normal, StatusLine and StatusLineNC, DiffChange and Difftext seems too low to me, on both backgrounds. That's the only real complaint I have after a cursory check.
I like the dark version a lot more than the light one overall. I think the colors in the light one are too subdued, but I'll have to test it properly tomorrow during daytime.
@neutaaaaan thx for input
Changes are:
- Add more contrast to Statusline vs StatuslineNC (dark)
- Add more contrast to Constant (light)
- Change difftext to cyan
- Add more contrast to Special vs Normal (dark)
I've been messing around with the light version this morning, made a few tweaks to better suit my taste, ended up reusing the palette of quiet, and I still wasn't happy with it for the same reasons I'm never happy with full-featured light colorschemes.
I wouldn't use it, because it makes my brain go haywire, but it's coherent, and the only thing I'd argue in favour of is a slightly lighter StatusLineNC at ctermbg=243.
The dark version I'm fine with, the only tweak I've really looked into was Statement at ctermbg=255 to make them just a touch less overpowering, but then that made Type stand out too much. It's probably fine the way it is.
No community involvement, 3 days from opened to merged… aren't we going a little bit too fast, here?