# Playing around with the new face @base syntax **URL:** \ **Category:** Help\ **Tags:** face\ **Created:** [April 27, 2019, 10:22am UTC](https://discuss.kakoune.com/t/playing-around-with-the-new-face-base-syntax/495 "2019-04-27T10:22:28Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Delapouite](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/delapouite/32/10_2.png) [@Delapouite](https://discuss.kakoune.com/u/Delapouite)\ **Post date:** [April 27, 2019, 10:22am UTC](https://discuss.kakoune.com/t/playing-around-with-the-new-face-base-syntax/495/1 "2019-04-27T10:22:28Z")
Hello I tried to played a bit with the new face syntax introduced in [https://github.com/mawww/kakoune/commit/4e24ba86cc95c51f78ebe9e77f1848b6760dbeb5](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? ---
**Author:** ![mawww](https://discuss.kakoune.com/letter_avatar_proxy/v4/letter/m/4bbf92/32.png) [@mawww](https://discuss.kakoune.com/u/mawww)\ **Post date:** [April 27, 2019, 11:39pm UTC](https://discuss.kakoune.com/t/playing-around-with-the-new-face-base-syntax/495/2 "2019-04-27T23:39:24Z")
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`). ---
**Author:** ![andreyorst](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/andreyorst/32/29_2.png) [@andreyorst](https://discuss.kakoune.com/u/andreyorst)\ **Post date:** [April 29, 2019, 11:52am UTC](https://discuss.kakoune.com/t/playing-around-with-the-new-face-base-syntax/495/3 "2019-04-29T11:52:21Z")
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` ---
**Author:** ![mawww](https://discuss.kakoune.com/letter_avatar_proxy/v4/letter/m/4bbf92/32.png) [@mawww](https://discuss.kakoune.com/u/mawww)\ **Post date:** [April 30, 2019, 6:20am UTC](https://discuss.kakoune.com/t/playing-around-with-the-new-face-base-syntax/495/4 "2019-04-30T06:20:19Z")
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. ---
**Author:** ![andreyorst](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/andreyorst/32/29_2.png) [@andreyorst](https://discuss.kakoune.com/u/andreyorst)\ **Post date:** [April 30, 2019, 8:48am UTC](https://discuss.kakoune.com/t/playing-around-with-the-new-face-base-syntax/495/5 "2019-04-30T08:48:45Z")
> [@mawww](#): > > using terminal colors here is just for example, you can of course use the `rgb:RRGGBB` syntax there. If I want to stay consistent with active colorscheme – I can’t. > [@mawww](#): > > 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. Sure, [but using terminal colors could lead to even more illegible colors](https://user-images.githubusercontent.com/19470159/56893644-0d24ec00-6a8c-11e9-8990-b6c2869eadc5.png) ---
**Author:** ![mawww](https://discuss.kakoune.com/letter_avatar_proxy/v4/letter/m/4bbf92/32.png) [@mawww](https://discuss.kakoune.com/u/mawww)\ **Post date:** [April 30, 2019, 11:45pm UTC](https://discuss.kakoune.com/t/playing-around-with-the-new-face-base-syntax/495/6 "2019-04-30T23:45:47Z")
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.