Port all templates to Colortemplate v3 syntax #246
Conversation
lifepillar
changed the title
We (Neovim) appreciate that! We include these colorschemes as part of Vim's runtime files, and being able to add a new colorscheme from your project is always one of the highlights of porting a runtime file update. I'm really impressed by all the care and effort that you put into these schemes, and I've heard nothing but praise for them! So I just wanted to take the opportunity to say "Thank you!" |
Funny you say that. Beyond a handful of complaints I have heard nothing positive or negative about our efforts. |
|
Then I should have commented here much sooner! (I have meant to for a while.) I can assure you that your efforts are seen and appreciated. (The bundled colorschemes used to be something of a joke and only really useful as a prank on a coworker; now they are actually useable, and it's even a tough choice which of them to actually use. My personal favorites are |
|
Well thank you. The original offering was indeed in a sad state and it wasn't exactly easy to fix the mess. We hope to be able to keep up as long as possible. There is still work to do, though:
|
Thanks! I'll take the opportunity to raise a question to everyone involved in this project and to Neovim developers if anyone is reading, since in Colortemplate v3 I have dropped Neovim compatibility. To what extent should people working on this repo care about Neovim? Not supporting Neovim means cleaner colorscheme's code, easier troubleshooting (one runtime vs two), and the possibility to move the scripts to Vim 9 script. On the other hand, such a move is going to… disappoint Neovim users and likely cause reactions such as this. The way I see it, Neovim and Vim are diverging more and more, so IMO the wisest choice is to have colorschemes and templates tailored to each system—which is the solution I have adopted with Solarized 8 and Gruvbox 8, where Neovim templates are in a separate branch and are compiled with Colortemplate v2 (which will continue to support Neovim). Just a few highlights:
|
You already know the answer, don't you? No extent whatsoever. This project is only concerned with Vim. If the stuff we do here works in Neovim out-of-the-box, then it should be thought of as a happy accident, not a design goal. Just like what is going on in the main repo vim/vim. You certainly can add Neovim support to colortemplate if you feel like it (that's your project after all) but you should probably put it behind a flag or something if combining Vim and Neovim stuff has any chance of falling apart in Vim. |
I didn't even know there was Neovim compatibility before 😅 Can you comment on that? In any case, I'm mostly concerned with being able to use the finished colorschemes (via Vim) in Neovim, not so much in the Colortemplate script itself (although it definitely looks neat).
Well, that's obviously up to you; as your stated goal is to be a Vim colorscheme incubator, anything above "not at all" is a nice surprise :)
Yes, that would be pretty much the only thing that would cut us off from your efforts (although there's https://github.com/tjdevries/vim9jit, which might be extendable to cover this). So as long as you feel comfortable sticking to "common vimscript" for these, it will be appreciated. (I should mention that I feel justified in such an ask -- once, and politely -- since it means you'll have a bigger audience, meaning more people coming with useful bug reports and PRs.) Everything else you've listed is our problem, and -- so far -- fairly easy to handle manually when I port Vim's runtime updates. And obviously you're not going to add Neovim-only highlight groups to your colorschemes (we handle these by having a reasonable default link to one of the standard groups). |
Answered in Colortemplate's repo. |
|
Thanks! I'll take the opportunity to raise a question to everyone
involved in this project and to Neovim developers if anyone is
reading, since in Colortemplate v3 I have dropped Neovim
compatibility.
To what extent should people working on this repo care about Neovim?
Whatever the answer is, if you advertise that the colorschemes work with
Neovim, you will need to test the colorscheme with both Vim and Neovim.
As mentioned, Neovim is making changes in various places, you cannot
simply assume that when a colorscheme works for Vim it will also work
for Neovim. Once you find a difference you can hopefully "hide" it in a
template or add some kind of test, but you do need to keep checking.
- Neovim has a new syntax for [scoped highlight
groups](https://github.com/neovim/neovim/blob/fdc8e966a9183c08f2afec0817d03b7417a883b3/runtime/doc/treesitter.txt#L350).
I don't know the details, but it looks very much like what every syntax
file has as a list of "hi def link" commands. Something that is
recognized as a specific item can be given a specific highlight, but
most users will just use the default translation to the limited list of
highlight groups used for Syntax highlighting.
If (and that is a big "if") treesitter syntax files are going be used by
Vim we might try to use the same names. Then colorschemes made for a
specific treesitter supported language could then work both in Vim and
Neovim. However, several people have voiced their opinion that
treesitter is not a very good choice. But there aren't many
alternatives. I'll have to dive into that at some point, once I have
sufficient time.
- Neovim has deprecated `t_xx` settings, so a colorscheme shouldn't
rely on `t_Co` to determine the available colors. See [this
thread](neovim/neovim#11974).
Dropping t_xx settings means that quite a few legacy Vim scripts stop
working. I thought that Neovim was keeping support for legacy Vim
script, but changes like this indicate otherwise. Anyway, Neovim users
that run into this should bring up the issue with Neovim. If this
happens often enough perhaps they will change their mind.
- With `termguicolors` on, Neovim uses `gui` colors *and attributes,*
but Vim keeps using `cterm` attributes.
For Vim this was decided at some point, and it's not going to change (it
would break lots of user's configuration). I suppose Neovim made a
different choice because they didn't have to worry about backwards
compatibility and thought using "gui" attributes is more logical. Which
is true, but then you cause colorschemes to be incompatible...
- Neovim does not (currently) support `ctermul`.
I suppose adding that to the :highlight command would be easy, but the
implementation very much depends on the terminal. I can't find a
reference to it in the terminfo manpage. It is implemented for xterm
(Vim has this builtin). Kitty does something similar, but I don't see
this reflected in the terminfo entry. Other terminals simply do not
support a different underline color. Depending on the support makes the
colorscheme unusable with quite a few terminals.
…--
You are not really successful until someone claims he sat
beside you in school.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
Absolutely. I think it's fair to say that this is not going to happen in this repo, as @romainl has pointed out. This project focuses only on Vim.
Yes, templating can act as an interface. Neovim developers can take the templates rather than the colorschemes, and use them to generate their own version of the colorschemes. This is already possible with Colortemplate v2. It will be possible with v3 if someone joins the Colortemplate project to take care of Neovim compatibility, as I am not a Neovim user myself.
AFAICS, they have been made read-only and marked as “deprecated”, but they still exist. But that means, for instance, that the user cannot set
That's why |
|
>Dropping t_xx settings means that quite a few legacy Vim scripts stop working.
AFAICS, they have been made read-only and marked as “deprecated”, but
they still exist. But that means, for instance, that the user cannot
set `&t_Co = 16` to force the use of the underlying terminal colors.
I did a simple search for this, but could not find information about it,
other than what can be found at ":help t_xx" in
http://neovim.io/doc/user/vim_diff.html
But there it says "Nvim does not have special t_XX options nor <t_XX>
keycodes to configure terminal capabilities.". That is not the same as
what you mention, where did you find that?
I haven't seen a rationale for leaving out the t_xx options (I haven't
tried searching much though).
> the implementation [of `ctermul`] very much depends on the terminal.
> […] Depending on the support makes the colorscheme unusable with
> quite a few terminals.
That's why `ctermul` attributes are never present in the colorschemes
of this repo. If would be nice if Vim could ignore the special color
unless it detects that it is supported.
Isn't it? The code doesn't do anything if t_AU isn't set.
…--
Although the scythe isn't pre-eminent among the weapons of war, anyone who
has been on the wrong end of, say, a peasants' revolt will know that in
skilled hands it is fearsome.
-- (Terry Pratchett, Mort)
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
|
> I've heard nothing but praise for them!
Funny you say that. Beyond a handful of complaints I have heard
nothing positive or negative about our efforts.
For most of this kind of work: "No news is good news".
Usually people only complain when they don't like something.
When it works fine then you don't hear anything.
Or nobody is using it, that's hard to tell.
…--
hundred-and-one symptoms of being an internet addict:
151. You find yourself engaged to someone you've never actually met,
except through e-mail.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
You are right, I can find mentions of “t_xx have been deprecated” only in some relatively old issue reports (e.g., neovim/neovim#16832 and neovim/neovim#11883). No idea about the rationale, except that being compatible with less capable terminals does not seem a Neovim requirement, and “Nvim startup is not blocked on waiting for the UI, including the TUI. So depending on a particular value of &t_Co during startup isn't going to work.” (neovim/neovim#5538 (comment)).
Ah, I see. I have my terminal misconfigured then… |
That is exactly the rationale. We have instead tried to make terminal feature detection as robust as possible. |
|
> "Nvim does not have special t_XX options nor <t_XX> keycodes to
> configure terminal capabilities.". That is not the same as what you
> mention, where did you find that?
You are right, I can find mentions of “t_xx have been deprecated” only
in some relatively old issue reports (e.g.,
neovim/neovim#16832 and
neovim/neovim#11883). `echo &t_xx` does not
raise error for any `xx` but afaics it returns nothing except for `t_Co`
where it returns `256`. So, yes, they are basically unsupported, not
just deprecated.
No idea about the rationale, except that being compatible with less
capable terminals does not seem a Neovim requirement, and “Nvim startup
is not blocked on waiting for the UI, including the TUI. So depending on
a particular value of &t_Co during startup isn't going to work.”
(neovim/neovim#5538 (comment)).
Related to Neovim having split the UI into a separate process?
From the user POV it's still one program though.
It is true that t_Co may have an initial value on startup and change
once we know more about the terminal. This happens especially for
xterm, which reports the number of colors interactively. The t_Co value
is updated later. If it changes and a colorscheme was loaded, it will
be reloaded.
So there is no "waiting for the UI" in Vim. The redraw triggered by
getting another value for t_Co can be annoying though (especially when
debugging and for running tests).
…--
hundred-and-one symptoms of being an internet addict:
155. You forget to eat because you're too busy surfing the net.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
This PR updates the syntax of all the templates to Colortemplate v3. I did it so you don't have too 😉
I am not asking to merge this at once. As Colortemplate v3 is still in alpha, this can be used to discuss issues and fix them.
Why upgrade? There are a number of reasons. I will mention just three:
Variantdirective has been dropped: instead, each highlight group definition has a unique default definition (which must appear first), and zero or more overriding definitions (which may appear anywhere in any order after the corresponding default definition).FIXMEtags.The generated code is different from v2's, but it is subject to change depending on your feedback. Generating Vim 9 script is also possible, but for now I have rebuilt the colorschemes in legacy Vim script.
Important: I did not check whether the rebuilt colorschemes are visually equivalent to the current ones. It is likely that I've made mistakes.