Question about dim and bold attribute in faces

1

I’m working on a colorscheme, that ambitions minimalism and a unique accent color, which could be personalized through a unique option.
Working with such a small palette, I’m using the dim attribute a lot.
I’m having an issue with how the bold attribute integrate when there is a dim value.

Explanations :
Here is a small snippet that reproduces the issue I’m having

face global PrimarySelection rgb:ffffff,rgb:212121+fg
face global SecondarySelection rgb:212121,rgb:ffffff+rdfg
face global keyword rgb:ff0000+bu

I’m using the revert + dim attribute with the SecondarySelection so the background (in foreground position here) is first dimmed then reverted into its background position. This allows me to have a dim version of the background color without having to use any extra color.
It might look stupid and using another color would be easier, but by doing this trick, the theme can be heavily modified with a single option change.

My issue comes with the bold attribute that “suppresses” the dim attribute.
screenshot_142641
Above, you can see that secondary selection does not work over a keyword.
screenshot_142646

I know I could fix my issue my adding +F to both Primary and Secondary selection, but I just wondered if there might be another way that won’t change the way everything looks when selected (since using F prevent any other attributes while in selection, which is not what I would like)

Thanks in advance, don’t know if I’m really clear ahah, sorry !

2

I tried to convert your snippet into a test-case:

kak -n -e "
    face global PrimarySelection rgb:ffffff,rgb:212121+fg
    face global SecondarySelection rgb:212121,rgb:ffffff+rdfg
    face global keyword rgb:ff0000+bu
    addhl global/ regex [a-z]+ 0:keyword
    exec CWW
"

In xterm, st, rxvt, QTerminal, and GNOME Terminal, I get the following:

image

In PuTTY and (some version of) Kitty, I get:

image

Originally, terminals only supported monochrome output, so to provide some variation they supported attributes like “dim” and “underline” and “reverse video”. Later terminals added support for 8 or 16 basic colours, but this conflicted with the attributes intended for monochrome output: sure, it’s easy to understand how to apply “underline” to colour 10 (“bright green”), but if somebody applies “dim”, should it be the same as colour 2 (“dark green”) or should it be its own thing? Even today, there is still some confusion on this matter - some terminals interpret the attribute combination “colour 2, bold” to mean “colour 10”, some use it to mean “use a bold font”, some do both, some leave that behaviour user-configurable.

Even later terminals added true-colour attributes into the mix, so what should happen if you combine rgb:00FF00 with the “dim” attribute? Some terminals will try to integrate decades of legacy support and make something reasonable, other terminals just say “if you’re using true-colour, you can pick your own colours and don’t expect me to guess”.

In regards to combining different character attributes, ECMA-48 just says “The usable combinations of parameter values are determined by the implementation.”

It’s a neat idea to have a colour scheme with one accent colour, algorithmically modified, but I don’t think it’s going to be portable to rely on the terminal to do those algorithmic modifications. If you really want to do that, I’d recommend maybe writing an awk script to generate the colour scheme given the base colour, and have it run in a WinSetOption hook.

3

Thank you so much for the clear explanation !
I think I’ll try to make it work using AWK as you suggested, or something similar :blush:

4

If someone wonders (doubt), I went with the following snippet to calculate dim colors :

calculate_dim() {
    printf "$1" | cut -d: -f2 | fold -b2 |
        while read -r hex; do
            base10="$(printf '%d' "0x${hex}")"
    	    printf '%02x' "$((base10 * 3 / 4))"
        done | xargs printf 'rgb:%s'
}

Might not be the prettiest but works good enough for me :blush: