(v3) Suggestion - Build-time color calculations

[briancarbone]

This would be a method for calculating relative colors at build time, e.g. a color with an "alpha layer" simulated atop a solid base color. I've seen color palettes (like ayu) generated using tools like https://gka.github.io/chroma.js/ (with lighten, darken, etc.). It would be nice to expose a high-level, build-time interface for manipulating colors. I'm not sure whether this would be used within the Color: directive or in some new way... perhaps RelativeColor:, but that may be redundant if some function-like interface is required, e.g. mix(#ABCDEFFF, #CECECEAA) (this seems like a poor example... there would need to be a way to reference other colors at a minimum).

Referencing libcolor here as well.

[lifepillar]

Thanks for opening this issue. Original discussion, for reference: #85.

[briancarbone]

I'm thinking about this more as I've decided to translate Ayu over to colortemplate... I'm not so confident about this suggestion anymore due to the number of challenges it creates. A significant number of colors in Ayu are defined in terms of other colors using chroma-js functions like lighten, darken, alpha, etc. Perhaps it should be expected that a template designer generates final values for each color as I've done below with the dark 'edition' of Ayu.

{
  "syntax": {
    "tag": "#39bae6",
    "func": "#ffb454",
    "entity": "#59c2ff",
    "string": "#aad94c",
    "regexp": "#95e6cb",
    "markup": "#f07178",
    "keyword": "#ff8f40",
    "special": "#e6b673",
    "comment": "#acb6bf8c",
    "constant": "#d2a6ff",
    "operator": "#f29668"
  },
  "vcs": {
    "added": "#7fd962",
    "modified": "#73b8ff",
    "removed": "#f26d78"
  },
  "editor": {
    "fg": "#bfbdb6",
    "bg": "#0d1017",
    "line": "#131721",
    "selection": {
      "active": "#409fff4d",
      "inactive": "#409fff21"
    },
    "findMatch": {
      "active": "#6c5980",
      "inactive": "#6c598066"
    },
    "gutter": {
      "active": "#6c7380e6",
      "normal": "#6c738099"
    },
    "indentGuide": {
      "active": "#6c738080",
      "normal": "#6c738033"
    }
  },
  "ui": {
    "fg": "#565b66",
    "bg": "#0b0e14",
    "line": "#11151c",
    "selection": {
      "active": "#47526640",
      "normal": "#47526633"
    },
    "panel": {
      "bg": "#0f131a",
      "shadow": "#00000080"
    }
  },
  "common": {
    "accent": "#e6b450",
    "error": "#d95757"
  }
}

I'm still left wondering whether there is an opportunity to permit alpha values in the template such that final values are calculated at compile time. Practically, this would require the background color of one highlight to be simulated against the background color of another highlight... I haven't made much progress yet, but I anticipate editor.selection.active would be simulated against editor.bg.

This isn't to say chroma-js-like functions are a bad idea, but I recognize they would require considerable syntactic adjustments.

Edit: Or perhaps some convenience Colortemplate command/color picker feature can manage it.

[lifepillar]

Perhaps it should be expected that a template designer generates final values for each color

I'm more for orthogonality of features, so I second this. What you propose seems like a plugin in itself.

Colortemplate has a color/style picker (:ColortemplateStyle). It's still in the v3 branch, but I'm working (way too slowly) to make it a separate plugin (based on libcolor). That plugin and libcolor might be the right places to put those calculations.

Btw, what's the role of alpha channels here? I don't think Vim supports transparent colors.

[briancarbone]

Alpha compositing can create the illusion of a color with transparency. In this example, the overlays are the same color (#6C7380) with different levels of transparency; the alpha-composited results don't retain that information.

background: #0d1017
editor.gutter.active #6C7380E6 (alpha-composited: #636976)
editor.gutter.normal #6C738099 (alpha-composited: #464b56)

Using a made-up syntax, this could be something like:

Color: editor_bg #0d1017 ~
Color: editor_gutter_active alpha-composite(srgb, #6C7380E6, editor_bg) ~

In the case of Ayu with "light," "dark," and "mirage" variations, pre-calculating lighten/darken (in the Lab color space) and alpha composition (in the sRGB color space) gets a bit tedious. It's not a huge deal.

[briancarbone]

This example has me thinking about the concept of "color namespaces" as well... perhaps a Namespace directive could contain Color definitions and then those colors could be referenced using a syntax like namespace.color.

Namespace syntax {
    Color: constant #abcdef ~
    Color: function #abcdef ~
    ....
}

Function syntax.function omit

I could make a separate issue if this is something you find appealing.