background_opacity + setbf(0, 0, 0) draws default background color, not black

[dankamongmen]

Describe the bug
kitty 0.19.3 draws the default background color instead of black when given setbf(0, 0, 0).

To Reproduce
Steps to reproduce the behavior:

1. Change the background color to 0, 0, 0 via \33[48;2;0;0;0m
2. Emit a character. Observe that the background is the default background color.
3. (optional) Change the background color to 0, 0, 1 via \33[48;2;0;0;1m.
4. (optional) Emit a character. Observe that the background is the expected 0x000001

Expected behavior
I expect setbf 0;0;0 to set the background color to 0x000000 (black). Perhaps I am wrong? Instead, kitty is setting the background color to the "default color".

Screenshots
Here, my kitty background is transparent.

The string I'm writing the second time is \33[?1h\33(B\33[0m\33[38;2;100;100;100m\33[48;2;255;255;255ma\33[48;2;0;0;0mb \33[48;2;0;0;1mc \33[48;2;255;255;255md\n.

Environment details
OS: Linux 5.10.1 on Debian Unstable using Notcurses 2.1.1

[schwarzgerat](0) $ kitty/launcher/kitty --debug-config
kitty 0.19.3 (3ce04c3e4b) created by Kovid Goyal
Linux schwarzgerat 5.10.1nlb #1 SMP Mon Dec 14 21:46:25 EST 2020 x86_64
Debian GNU/Linux bullseye/sid \n \l
Loaded config files: /etc/xdg/kitty/kitty.conf, /home/dank/.config/kitty/kitty.conf
Running under: X11

Config options different from defaults:
background_opacity    0.7
enable_audio_bell     False
font_family           Hack
update_check_interval 0.0
[schwarzgerat](0) $ 

Additional context
This behavior does not occur with --config NONE. It appears to require background_opacity N where N < 1.0.

background_opacity 0.7

[kovidgoyal]

This is intended behavior. Background colors that exactly match the default background color, whatever it may be are rendered as transparent. IIRC this was done so that applications like alsamixer that dont set the default background color still are transparent, see 2045055

[dankamongmen]

Got it. I'm unaware of any other terminals with this behavior, but that doesn't make it "wrong". Do you expose any (non-standard) terminfo capability expressing this behavior? If not, would you consider doing so?

So in the case above, where I've got a (partially-)transparent kitty, and a default background color N, and I authentically want a background of N (not transparent), is there any way to get it? I.e. in the example above, how do I get a black background? Apologies if I'm missing something obvious.

[dankamongmen]

I guess if I can detect the configured default background color, I can match that against my desired color, and if they're equal (and the hypothetical terminfo capability has been detected), I could emit op (and possibly setaf) instead of setbf. That would work just fine, so long as I have the terminfo capability, and I can look up the default background color.

[dankamongmen]

alternatively...may I ask how committed to this feature you are? I can understand the appeal and motivation for the original change, but it's in my opinion an unexpected departure from the norm, and it seems to be causing problems for other applications (see the broken Vim screenshot in the original bug). I think it was a neat idea, but in practice it seems to punish certain classes of applications. Just a suggestion; I don't mean to offend.

[kovidgoyal]

I dont know about other terminals though I have a vague memory that alacritty does this too, but maybe I am mis-remembering.

No, there isn't any way of forcing background color to non-transparent. Your best bet is to use a color that's just off the background color, like (0, 0, 1). So you would set the default bg to X and use X+1 as the forced opaque bg color.

I actually dont like this behavior at all, however, the sad state of affairs is that a lot of applications alsamixer/vim for instance, dont set default bg color and instead color all cells with their background color, without this behavior, they would become unuseable with transparency.

You can query colors, there are escape codes for it, but rather than use those, you could just set your own and save/restore the previous ones using this: https://sw.kovidgoyal.net/kitty/protocol-extensions.html#saving-and-restoring-the-default-foreground-background-selection-cursor-colors

As for terminfo capability, it would need to be custom, so only kitty's terminfo would have it, so why bother, just detect kitty instead. You can use the existing escape code to query terminal name, or get it from terminfo or use https://sw.kovidgoyal.net/kitty/kittens/query_terminal.html

[dankamongmen]

Thanks for the detailed response, @kovidgoyal . Alright, let's close this down as works-as-intended.

For what it's worth, no, current alacritty does not have this behavior (see image below). I only see it in Kitty from my testing matrix of { xterm, mlterm, alacritty, kitty, konsole, xfce4-terminal, gnome-terminal, sr }.

I don't love the idea of changing the default color, since the user presumably selected one (in the case of non-default) purposefully. I'll look into whether that color can be retrieved, and do that if so. Otherwise, I'll probably go with the save/restore.

[kovidgoyal]

You can definitely query them using OSC escape codes, see https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Operating-System-Commands

[dankamongmen]

You can definitely query them using OSC escape codes, see https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Operating-System-Commands

indeed, thanks for the pointer!