Playing around with the new face @base syntax

Help
1

Hello

I tried to played a bit with the new face syntax introduced in https://github.com/mawww/kakoune/commit/4e24ba86cc95c51f78ebe9e77f1848b6760dbeb5 and I think I don’t understand fully how it works.

Let’s open a stock kakoune with kak -n. We see the *scratch* buffer with its default content.
These 2 lines have the Default face.

First, let’s use the old syntax:
face global Default Information

The buffer lines now have a black fg and a yellow bg. Great.

As stated in the commit message above, this is the same as using:
face global Default default,default@Information

Now let’s try to set some bold. The following are equivalent:
face global Default +b@Information
face global Default default,default+b@Information

The buffer lines are have a black fg, a yellow bg and the text is bold.

So far so good.

Starting from now here are the syntaxes that I don’t understand.

I attempt to reuse Information except changing the fg color.
These commands result in parsing error:
face global Default red@Information
face global Default red,default@Information

I was expecting to have the buffer lines have red fg and yellow bg.

Same failure for changing only the bg color. Parsing error:
face global Default default,red@Information

Surprisingly, these commands work if an attribute like +b is applied:
face global Default red+b@Information
face global Default red,default+b@Information
face global Default default,red+b@Information

Am I missing something obvious about this new @base syntax? Should the parsing errors described above be legit syntax?

2

The parsing code was bugged and did not support bases with no attributes, this should be fixed now.

Note that there is a subtility in bases when a face is based off itself it will mutate the face (so, after face global foo red,default@bar; face global foo default,blue@foo, the foo face should be red,blue@bar).

3

I don’t like the whole idea of using terminal colors when making custom faces. If terminal colorscheme significantly different from Kakoune colorscheme, the colors will look out of place and may be hard to read.

I thought that creating new faces based on other faces would allow us to use face colors, like set-face global newface string.fg,Error.bg+b

4

using terminal colors here is just for example, you can of course use the rgb:RRGGBB syntax there.

Being able to refer arbitrary faces fg/bg colors separately would be a bigger refactoring, which could be nice although its not obvious to me that it would lead to predictibly legible colors.

5

If I want to stay consistent with active colorscheme – I can’t.

Sure, but using terminal colors could lead to even more illegible colors

6

I agree, I consider terminal color support a legacy feature we need because we cannot always assume the terminal support 256colors with mutable palette. I expect colorschemes to either always use rgb colors or always terminal colors, but never mix/match them.

It would be nice to identify what kind of operations we would want to make on existing faces and see if we can support them via attributes. For example we could handle the reverse attribute internally (instead of passing it to the terminal) which would provide a way to reverse any face (+r@base), similarly we could have support for dim/brightenning of rgb colors…

I agree there are some use cases better served by named colors (diff highlighting for example, where green/red is a very well established convention), but if we can get 80% of the flexibility without having to introduce a new concept that makes faces dependent on options, I would be happier.