Open lifepillar opened 1 year ago
Thanks for the explanation! To be clear, I originally did not realize you meant the template generator instead of the generated colorschemes.
I haven't ported the Neovim directive to Colortemplate v3, and I don't plan to do it.
That is fine; whatever makes your life easier for making high-quality colorschemes. If legacy vimscript is supported, that is more than enough for Neovim (and more than can be expected).
To be honest, I see three valid targets here (as anywhere):
My personal view is that for anything that is not performance-critical or editor-specific (because of custom APIs), option 1 is the best choice.
(Conversely, if you are interested in how Lua colorschemes would look, even if only out of curiosity, hit me up.)
I didn't even know that you could write colorschemes in Lua in Neovim.
The current situation is that use case (1) is addressed by Colortemplate v2 only (in v3 only for Vim); (2) is addressed by Colortemplate v3 only; and (3) is not supported. My idea was to continue using v2 for use case (1), but given that there are more use cases, I now believe that the best course of action is to improve the support for adding code generators in v3, put v2 in maintenance mode, and find some brave soul to implement one (or more) generators for Neovim.
Again, as long as you keep generating OG vimscript, we're fine, no reason to worry about it even if you solely target Vim. If you drop that and only generate vim9script, we'll have to deal with it somehow.
On a more general note, what makes colorschemes more portable (and tunable, and extandable) is to define named colors, and then use only those in the highlight groups. (Like Nord does, for example.)
makes colorschemes more portable (and tunable, and extandable) is to define named colors
That's a possible approach, but it makes the colorscheme slower to load. I did write an experimental generator that uses named colors the way you say, but it needs to be iterated upon.
Anyway, I am confident that, one way or another, a solution that works for almost everyone will be found.
Anyway, I am confident that, one way or another, a solution that works for almost everyone will be found.
The current solution already works for almost everyone, is all I've been trying to say :)
[This is a question from Vim's colorschemes repo, which I am answering here to keep things on-topic.]
Colortemplate v2 (but not v3) can parse a
Neovim
directive, which can be added to a template and set toyes
or toonly
. When set toyes
, the generated colorscheme is compatible with both Vim and Neovim: this the most compatible option, as it generates a colorscheme that should work everywhere. When set toonly
, the colorscheme is optimized forNeovim
only: there are noif has('nvim')
statements and no use oft_xx
options (except as a fallback),g:terminal_ansi_color
is not generated, … maybe something else I don't remember.I haven't ported the
Neovim
directive to Colortemplate v3, and I don't plan to do it. Colortemplate v3 has abackend
setting, though, which can be used to set the “backend” code generator. For now, it supportslegacy
Vim script, andvim9
script. It is not too difficult to add a new backend, so aneovim
backend may be feasible. But if we go that way, I'd like someone else to help maintaining Neovim compatibility, as I am not a Neovim user. I plan to open this project to collaborators when v3 enters the beta stage, so if you are interested let me know!