Subject: Re: bug#15444: One character can be lost if colors are enabled

From: Paul Eggert <[email-masked]>
Date: Wed, 27 Mar 2024 14:35:37 -0600

On 3/27/24 02:15, Egmont Koblinger wrote:
> The problem is that if you're at the bottom of the screen and
> autowrapping occurs, the entire new line is added with the currently
> active background color, which might not be the terminal's default
> background color. If that new line isn't filled with text entirely
> then the rest remains with that color.

Thanks for the detailed analysis. Surely the issue quoted above is the 
main problem. That is, grep (and other programs) should be able to 
output color changes without knowing or worrying about line length, and 
shouldn't have to do any hack like what grep does now, where it switches 
back to the default background color and clears to the end of the line 
(and here I'm talking about either the current grep behavior, or the 
\e[3K of urxvt).

Shouldn't there be a better way to do things - perhaps a new escape 
sequence that grep etc. can use, which says "I don't know what the 
physical line length is and I don't care"?

> I'm puzzled how
> upstream grep, for many-many years, has chosen to possibly chop off a
> letter as its default behavior

A good chunk of this is plain caution, as you can see from the bug 
report. No matter what we do it'll be "wrong" for some users and we've 
lacked the time or desire to think things out as carefully as you have.

> Like Vincent's idea
> with a space + backspace. Or space + backspace + clear-to-eol

I dunno, those hacks would likely just compound our misery. They sounded 
a bit like trying to clean the lipstick off a pig. We're better off not 
adding the lipstick in the first place, or even better yet not buying 
the pig.