Fix lines in kitty terminal with text_fg_override_threshold set

[joveian]

The kitty terminal has a new setting text_fg_override_threshold that checks the luminosity difference between the text and background and if it is above the set percentage turns the text black or white to get the best possible visibility. pastel currently uses a unicode half block character and sets both forground and background to the same color in the color patch. This patch changes this to be a space with both forground and background colors set to the same color (only becuase I don't know enough rust to figure out how to just set background color :/).

Possibly this could cause trouble with some background transparency settings, although if so the current situation might as well to a lesser extent. I'm not sure how to make using text color work reliably with text_fg_override_threshold so I think a command line option to use one or the other would be needed there unless another drawing option is used.

There are two other ways to draw on kitty that could be considered. The graphics protocol allow arbitrary images to be displayed and is supported by a few other terminals. kitty also supports using colors with DECCARA, although I don't know if any other terminals support this. In any case, with this patch it works for me and I checked that it still works on alacritty as well.

[sharkdp]

The kitty terminal has a new setting text_fg_override_threshold that checks the luminosity difference between the text and background and if it is above the set percentage turns the text black or white to get the best possible visibility.

I saw the upstream issue (https://github.com/kovidgoyal/kitty/issues/6767). Is the strategy really to try and fix every program that uses "last century" mechanisms for drawing in the terminal?

There are two other ways to draw on kitty that could be considered. The graphics protocol allow arbitrary images to be displayed and is supported by a few other terminals.

If you want to explore this, this sounds like a great idea. This could certainly result in nicer graphics for those terminals that support the protocol. Maybe we could open a new issue for this, listing potential benefits.

[joveian]

Is the strategy really to try and fix every program that uses "last century" mechanisms for drawing in the terminal?

I don't think there is any intent to remove support for ANSI color. The one color related thing that kitty doesn't support (and I don't think ever has) is the background color erase (bce) functionality due to major issues with the design (and as a result conflicting implementations).

Unfortunately, the text_fg_override_threshold setting is quite useful because of the variety of terminal color settings and the many programs that just use what works for the developer without options to change color (or just it being very annoying to change all the colors). I suspect there are many fewer non-text uses of low luminosity fg vs bg color combinations and some of those would be better off applying the override. Personally I would like web browsers to implement this feature as well to fix the occasional unreadable page.

If you want to explore this, this sounds like a great idea. This could certainly result in nicer graphics for those terminals that support the protocol. Maybe we could open a new issue for this, listing potential benefits.

I'm not sure using the graphics protocol would really make much difference for what pastel does. Unless you want to use harfbuzz to produce proportional font example text or something like that? Or if there turn out to be background transparency issues that using the graphics protocol fixes.

[sharkdp]

Ok, thank you for the explanations. I guess there's no harm in merging this if it helps kitty users.

I'm not sure using the graphics protocol would really make much difference for what pastel does.

Ok