alternative to changing saturation?

[dhduvall]

I wanted to try out the new inlay hints in vim, now that I have a whole stack that supports them (vim, vim-lsp, Go settings, and gopls). I wanted the hints to show up in a lighter color than the default, which just uses Normal. I'm using vim-solarized8 and have been doing my experimentation with the light background. I discovered this plugin (and OMG, it's awesome), but was unable to get what I wanted.

Specifically, I wanted to start with Normal and move the foreground color along the path towards the background color. I guess it's sort of like changing saturation, but with the background as a target instead of white. It seems like this would probably be more useful for a color theme design tool than traditional saturation, except when choosing a base color.

Does this make sense? I don't know color much at all, so perhaps not.

[lifepillar]

You are talking about :ColortemplateStyle, right?

I see two problems with your request: first, there are many ways to transition from one color to another, so you would need to define what a “transition path” means. Second, there are different possible design choices for such a feature in the style dialog: off the top of my head:

• let the user clip the bounds of the color bars in the RGB and HSB panes according to some source and target color.
• Add a new pane specifically for color transitions.
• Connect the bars, say in the HSB space, so that when you change one, the others move automatically based on some target color (?).

Getting any of these right (also in the sense of usability) is non-trivial and would need some research (I am not a color expert either!). It would also increase the complexity of the style dialog, so one should evaluate whether the benefit the feature brings is worth it.

For your specific, example, I would use the style dialog as follows. First, take a look at the HSB values for Normal's background color:

Now, switch to the foreground (Shift-Tab):

So, to transition from fg to bg in this color space you essentially need to increase the saturation and decrease the brightness (hue is almost the same). You can do that by hand, with some trial and error. Not ideal, but not too difficult either. But this is probably what you are doing now anyway, so I know that this is not a very helpful suggestion.

An alternative is to use a real color editor, one of the many you may find on the web or the one provided by your OS. If you find the functionality you want implemented somewhere, I may take a look and try to port the feature to Colortemplate. Having a reference specification would be of great help.

[dhduvall]

Well, this got more complicated than I thought, and pretty quickly. 😃 Here are some not-too-deep thoughts.

I guess there are two decisions in this: what does "transition" mean here, and what would the UI look like?

I poked around regarding color gradients, and thought that https://raphlinus.github.io/color/2021/01/18/oklab-critique.html was a pretty good writeup (and the tool was useful, too). Plugging in the foreground and background Solarized colors gets me the gradient I want, though these colors don't elicit much distinction between the colorspaces. There's a lot written about transitioning between two colors, and it's too much (for me) to take it all in. But it looks to me like the idea would be to choose a colorspace definition and do a linear transition in that context, much like the gradients in the tool.

As for the UI for the hypothetical colortemplate feature ... I don't have anything to point you at. I think what I'm envisioning is your second option. In that pane, you have a single slider (position along the gradient) and a preview of the entire gradient (quantized as best you can in a text UI). You'd need some way of choosing the colorspace (having multiple on-screen simultaneously like in that blog entry is probably too overwhelming) if the plugin doesn't make the choice for you (and the implementer has the time and energy to implement more than one). And some way of choosing the endpoints. For my use-case, that could simply be using the fg/bg of the current cell so you wouldn't need any extra UI. But maybe someone can think of other use-cases that would require a chooser.

Using the current fg/bg seems a bit slippery—as those values change, in this pane or any other, then do the endpoints change? That seems pretty bad. It could stay fixed at the fg/bg when the dialog came up.

I don't know how compatible the code on that page is with the code you've written or how the licensing would work (it's Apache 2.0), but I hope it would reduce the implementation effort, should you (or I, but probably not) choose to do it.

[lifepillar]

Thanks for the link, that's very helpful! Yeah, something like that would have to be done in a new pane.