Commit c7f0542 breaks compilation of vim-solarized8

[Ontonator]

When the latest version of vim-solarized8 is compiled with versions after commit c7f0542, loading the colour scheme reports errors stemming from the fact that s:termtrans is unset, but finish is omitted. Compiling using the version in commit c66f4e5 produces a working colour scheme with finish present after each unsetting of s:termtrans. I don't know enough about colour schemes or colortemplate to know the cause of this.

I wasn't sure if this was a vim-colortemplate issue or a vim-solarized8 issue since I wasn't sure what stability guarantees vim-colortemplate intends to provide, but I assumed that since I couldn't find any mention of this change being a breaking change, it was probably not known/intended.

[lifepillar]

Thanks for reporting! That sounds like a regression: I will look into it.

FYI: my goal is for this plugin to remain as stable as possible. Except for bug fixes, I consider it essentially feature-complete (but, to be clear, not abandonware! I plan to maintain support for the time being). I am (slowly) working on a major (mostly internal) overhaul of Colortemplate, which will break backward-compatibility in several ways, but I will likely release it as a different plugin for that reason.

[lifepillar]

Can you try the current master of vim-solarized8? This should be fixed there.

A bit of context

Up to recently, Colortemplate used to generate “minimal” highlight group definitions. For instance, if you used the GUI or a terminal with millions of colors, it only set guifg, guibg colors; if you used a 256-color terminal, it only set ctermfg, ctermbg colors; etc. It seemed sensible to me: e.g., why would you need ctermfg when you use GUI Vim?

It turns out that there are use cases for wanting a complete highlight group definition, independent of the current environment. So, Colortemplate's output was considered buggy, and it was fixed recently, especially for the Vim's colorscheme project.

Hence, the solution to your issue was to update Solarized 8''s template code accordingly.

This highlights (pun intended) a design problem with Colortemplate, which has bugged me for a while: to use Colortemplate's verbatim blocks you must have a more or less accurate idea of how the generated output will look like. While they introduce a lot of flexibility, they also make it impossible, in general, to modify the generated color scheme in a backward-compatible way. It is as if you'd need to know what assembly code your compiler produces in order to write correct source code.

This is something I'd like to resolve with the revised plugin I'm working on. Ideally, the template code should be fully declarative. Not an easy task to achieve, though, without limiting the expressiveness of the template.

[Ontonator]

Yep, looks like it is fixed now. Thank you for the swift replies, and sorry for reporting this here instead of in vim-solarized8. (Also, thanks for maintaining both of these projects.)