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
Hello,
VTE co-developer here. (VTE, a.k.a. libvte is the terminal emulation
widget behind GNOME Terminal and several other terminal emulator
apps.)
Note that this very bug is also filed at https://savannah.gnu.org/bugs/?36831 .
---
The "background color erase" ("bce") feature of most terminals
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 esc
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 s
- Original Message -
> On Mon, Sep 23, 2013 at 6:34 AM, Jaroslav Skarvada
> wrote:
> > printf
> > '1234x\n'
> > | grep 1234 --color=always
>
> Thank you for the report.
> I confirm that setting GREP_COLORS
On Mon, Sep 23, 2013 at 6:34 AM, Jaroslav Skarvada wrote:
> printf
> '1234x\n'
> | grep 1234 --color=always
Thank you for the report.
I confirm that setting GREP_COLORS=ne is a work-around. Does that
have unwel
Reproducer:
$ printf
'1234x\n'
| grep 1234 --color=always
123x
This can be reproduced at least on xterm and linux console,
but i
