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

[cben]

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

[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]

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.

[cben]

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