Q: Can you elaborate on the Neovim compatibility directive? And why doesn't it exist in v3? about vim-colortemplate HOT 5 OPEN

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):

1. vimscript (v1) if you want to target both Neovim and Vim (and Vim8, and Vim7, and...);
2. vim9script, if you want to target Vim9 only;
3. Lua, if you want to target Neovim only.

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.)

from vim-colortemplate.

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.

from vim-colortemplate.

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.)

from vim-colortemplate.

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.

from vim-colortemplate.

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 :)

from vim-colortemplate.