Q: Can you elaborate on the Neovim compatibility directive? And why doesn't it exist in v3?

[lifepillar]

[This is a question from Vim's colorschemes repo, which I am answering here to keep things on-topic.]

I didn't even know there was Neovim compatibility before 😅 Can you comment on that?

Colortemplate v2 (but not v3) can parse a Neovim directive, which can be added to a template and set to yes or to only. When set to yes, 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 to only, the colorscheme is optimized for Neovim only: there are no if has('nvim') statements and no use of t_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 a backend setting, though, which can be used to set the “backend” code generator. For now, it supports legacy Vim script, and vim9 script. It is not too difficult to add a new backend, so a neovim 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!

[clason]

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

[lifepillar]

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.

[clason]

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

[lifepillar]

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.

[clason]

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