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.
