Commit `c7f0542` breaks compilation of vim-solarized8 about vim-colortemplate HOT 3 CLOSED

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

from vim-colortemplate.

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.

from vim-colortemplate.

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.

from vim-colortemplate.