GNU bug report logs -
#15444
One character can be lost if colors are enabled
Previous Next
Full log
View this message in rfc822 format
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.
This bug report was last modified 1 year and 79 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.