Face definition by indirection — define base16 named colors, or faces to inherit from?

[cben]

I'd like to tweak some things, e.g. the mode line, and maybe style some things not currently styled. But if I use customize-face I see the colors controlled by base16 already resolved to fixed colors such as #93a1a1, and I can only replace them by another fixed color — they'll not change when I flip between face16 themes.

IIUC if I want to change a face to parametric e.g. "use base0B background, whatever it is", the current solution is to fork base16-theme-define?
This is consistent with the base16 concept of a "builder", generating a theme of fixed colors, but in Emacs I think we can do better by adding indirection 💡

• First improvement I can think of is to add a customizable variable that will be combined with fixed list in base16-theme-define. Or did I miss something like that?
  But that's still requires finding it, not using normal emacs mechanisms to define faces...

• Can we define named colors? I can customize a face to have :background "light coral", can we extend that list so one could do :background "base09"?

  https://www.gnu.org/software/emacs/manual/html_node/elisp/Color-Names.html — hmm these all sound like named colors are read-only :-(

• Alternative: can we define 16 base faces setting foreground to one of these colors + 16 base faces setting background to one of those?

  • And then change theming to use fixed face definitions inheriting from 1 or 2 of those base faces, only re-defining those 32 faces when switching themes?
    This is optional, but would improve discoverability — if I inspect/customize say font-lock-function-name-face, I'd see it's defined to inherit from "foreground-base0D", not #268bd2...

[cben]

BTW, current mechanism for special-handling base16-settings-mode-line-fg and a few other values in base16-transform-color-key, could also be replaced by face inheritance.

[belak]

base16-theme-define exists largely to handle boilerplate in properly defining a theme. Specifically around 256 colors vs terminal vs graphical. Other additions for settings were done because the theme define was already there.

If you can find a convenient way to do this and avoid face definitions tripling in size, I would be open to it.

Theme customization has been on my radar but I haven't had the time to devote to it. In theory you should be able to call base16-theme-define a second time with only the faces you want to override but I don't think that works quite right - that's how I'd picture overriding working.

On the inheritance side, that might work better than settings. That's a good idea.

I'm not sure on having faces for all the base16 colors though... Since they sometimes get used in box definitions as well, we'd need to inherit everywhere there was a different box definition.

[belak]

Thanks for taking the time to write those suggestions out! Elisp isn't one of my stronger languages, so if there's a better way to do something, I'm all ears.

[belak]

Sorry about the misinformation... I was on mobile this morning. base16-set-faces should be used to set faces. Then you can have a set of any definitions you want using the base16 colors. That's the portion I'm not sure works properly after the theme has been defined.

It would be nice if it was possible to call base16-theme-define to create the theme itself then use base16-set-faces to update any faces you want.

[cben]

Thanks, I'll play with base16-set-faces...