On 2016-07-14 14:22:15 -0700, Vincent Lefevre wrote:

On 2016-07-14 09:02:48 +0200, Walter Doekes wrote:

Leon Meier wrote:

As of today, the test case [...] still fails in (u)xterm.
Any resolution in sight?

I tried to reproduce, and indeed, it fails on xterm (without the 'ne' grep option), but not in gnome-terminal.

Does that mean that this is an xterm bug again and not a grep bug?

It is GNOME Terminal that is buggy, so that the grep bug is not
visible.

A solution for "grep" would be to add a space+backspace before the
escape sequence.

Testcase:

for i in `seq 5` ; do printf "%0$(($(tput cols)+i-5))dab \bc\n" ; done | \
GREP_COLORS="mt=41;97:ne" grep --color c

This works fine in Xterm, giving on a 80-column terminal:

0000000000000000000000000000000000000000000000000000000000000000000000000000abc 00000000000000000000000000000000000000000000000000000000000000000000000000000abc
000000000000000000000000000000000000000000000000000000000000000000000000000000abc
0000000000000000000000000000000000000000000000000000000000000000000000000000000abc
00000000000000000000000000000000000000000000000000000000000000000000000000000000abc

where only the "c" has the red background.

However, this triggers the bug in GNOME Terminal (and other
libvte-based terminals):

0000000000000000000000000000000000000000000000000000000000000000000000000000abc 00000000000000000000000000000000000000000000000000000000000000000000000000000ac 000000000000000000000000000000000000000000000000000000000000000000000000000000abc
0000000000000000000000000000000000000000000000000000000000000000000000000000000abc
00000000000000000000000000000000000000000000000000000000000000000000000000000000abc

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-03-25 15:49:52 +0100, Vincent Lefevre wrote:

A solution for "grep" would be to add a space+backspace before the
escape sequence.

An additional note: One of the following is needed:

* Detect the end of line (this may be tricky) and split the coloring
into 2 parts (each one with space + backspace + escape sequence)
at this point. If this detection is incorrect, then the background
problem would still be visible, but with no major drawbacks.

* Split the coloring so that each matching character gets a space +
backspace + escape sequence. I think that this is acceptable since
this trick should be used only when the output is a tty (i.e. it
is not redirected to a file / not piped to a pager or something
else).

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/25/24 08:49, Vincent Lefevre wrote:

This works fine in Xterm, giving on a 80-column terminal:

...

However, this triggers the bug in GNOME Terminal (and other
libvte-based terminals):

That's not good. Is there some escape sequence that will work on both
xterm and libvte? I assume the space+backspace trick you suggested later assumes xterm behavior.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-03-26 11:47:26 -0600, Paul Eggert wrote:

On 3/25/24 08:49, Vincent Lefevre wrote:

This works fine in Xterm, giving on a 80-column terminal:

...
However, this triggers the bug in GNOME Terminal (and other
libvte-based terminals):

That's not good. Is there some escape sequence that will work on
both xterm and libvte? I assume the space+backspace trick you
suggested later assumes xterm behavior.

I've eventually found that this works in xterm only because
I have the reverseWrap option set (a setting I've had since
at least June 1996... so that I forgot about it). In the past,
I think that I set it in order to be able to go backward to
the previous line in cooked mode. But this is not the default
behavior in xterm (at least nowadays).

It could still be nice to have this trick in grep as an *option*
for GREP_COLORS (just like one already has "ne").

But perhaps the best solution would be to make terminals implement
new escape sequences to enable/disable the use of the default
background color (instead of the current background color, which
is the current behavior and the cause of this bug) for the new line
when scrolling, or something similar.

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)