(v3) Suggestions - build-time color calculations & support for multiple variants of a background type

[briancarbone]

Hi, there. I've been using colortemplate v3 for quite some time and while these suggestions are by no means necessary, I think they would prove to be commonly leveraged core features.

1. Build-time color calculations

The final interface for this may require consideration and iteration, but I think it would be valuable to define colors in terms of other colors without pre-computing those values. For example, you may have three background shades that simulate colors with non-0xFF alpha values laid atop some base color. I'm somewhat reminded of CSS's color-mix function. I quite often see implementations in non-colortemplate systems where the maintainer will implement helper functions to calculate colors. It would be very nice if a color could be calculated and then the ~ placeholder could be used to produce the 256 variant at build time as well if desired.

I haven't thought too deeply about the user experience as the idea of a build-time function is novel to the project.

2. Multiple variants of a single background type

I use the word "variant" in the general sense and not specific to colortemplate's specific definition of "variant." Many colorschemes will offer two or more dark (or even light) options. Catpuccin and Kanagawa come to mind (with four and three different dark background variants or "editions"—if you will—respectively). In colortemplate, I suppose it would be sensible to define highlight groups in one file and then color definitions in other files that then import the highlight definitions... but as most time is spent modifying highlight groups, this would mean the plugin's main UI and feature set are lost (e.g. editing a file like _highlights).

The experience of specifying a colorscheme with an edition should probably be something like colorscheme name-edition, like colorscheme catpuccin-mocha wherein the colorscheme editions are independent and fully self-contained without inviting global variables. With that said, perhaps generating these editions could be more idiomatic in colortemplate. Please do let me know if there is a nice way of achieving this already; I had a play around with solving this and I didn't quite get there.

Edit: I'll add that the experience of defining Background: dark and Background: light sections using the same color names followed by Background: any to generate outputs for both is very nice. I was thinking of this when considering this suggestion. Maybe a syntax like Background: dark <edition name> could work? Just popped into my mind; needs consideration.

Thanks for creating this plugin—it is excellent.

[lifepillar]

Thanks for your feedback!

Build-time color calculations

Functions like those would be a good fit for libcolor in vim-devel. That library still needs quite a bit of polishing, but it is already used by Colortemplate v3.

Regarding a potential syntax extension for Colortemplate… I'm not sure I understand your use case: would care to elaborate, perhaps with a concrete example?

The workflow I typically use is to add to a template a palette created elsewhere, then interactively tweak the colors in Vim using the style picker, then update a color in the template when I find a better one. What you are suggesting sounds to me like something that would be done before the “add a palette to a template” step.

Multiple variants of a single background type

The idiomatic way to support that in Colortemplate is as you say:

define highlight groups in one file and then color definitions in other files that then import the highlight definitions

Gruvbox 8 and Solarized 8 show how I do that for a couple of somewhat complex themes with multiple “editions”, to use your terminology. That is as complex as it can get. I'm not sure that a syntax extension would be a significant improvement over the current way of doing things, but I didn't give it much thought and I'm open to discuss concrete proposals. I'd like the syntax to be more or less fixed when v3 is officially release, so this is something I may want to address sooner than later.

as most time is spent modifying highlight groups, this would mean the plugin's main UI and feature set are lost

If you mean that there's no toolbar for files prefixed with an underscore and you have to switch back and forth between the main file and an included file, then yes, I see how that can be inconvenient. Off the top of my head, it's a usability issue that can be fixed in at least two or three different ways.

A kind request: to follow up on these discussions, would you mind opening separate issues, one for each specific request, linking to this one, and then close this issue? This is so each thread can stay focused on a particular aspect and the discussion does not get diluted among several topics.