Conversation
v710 introduced a regression where wrapped lines (after the first
wrap) would get their color removed when scrolling down (off the top of
the screen) and then back up. The initial line retains its coloring,
but any wrapped lines afterwards get reset to normal.
For instance:
--- top ---
long colored line ...
wrapped long colored line 1 ...
wrapped long colored line 2 ...
wrapped long colored line 3 ...
wrapped long colored line 4 ...
Now, scroll down 3 lines, and back up 3 lines, then you see:
--- top ---
long colored line ... # still colored
wrapped long colored line 1 ... # color reset
wrapped long colored line 2 ... # color reset
wrapped long colored line 3 ... # still colored
wrapped long colored line 4 ... # still colored
You can reproduce with something like:
echo -e '\x1b[33m' word{1..9999} '\x1b[0m' | less --wordwrap -R
and then scroll down and back up.
This appears to be an unintentional regression, because the color is
restored to the wrapped lines if you hit CTRL-L or send less a SIGWINCH.
(My use case is I use `less --wordwrap -R` as a viewer/reader with my
own ansi 'dark mode' theme, with amber text and other markup. It's worked
perfectly in the past, but after updating to v710, this regression
appeared and it's pretty jarring when I scroll back up, unfortunately.)
I did a git bisect which pointed to f432d2d as the change that
introduced the regression.
That commit curiously moved the `loop:` label in input.c from after the
prewind()/plinestart() calls to just before them. Was that intentional?
I haven't studied the code carefully enough to say with any confidence.
But it is not explained in the commit message and I wonder if it was
accidental.
Moving the loop label back to its pre-f432d2d position fixes the color
getting removed from wrapped lines regression, and still displays the
marks correctly with `-J`, according to the reproducer steps in gwsw#820.
|
Moving the loop label in f432d2d was intentional. This patch reintroduces the bug that was fixed in f432d2d. After applying this patch, run |
|
Can the test cover such issues? If yes, it's worth adding (both marks and colors with wrapped lines). |
Ah, ok. The steps to reproduce in #820 had only mentioned typing
Cool, thank you! |
|
Yes, lesstest could cover this case. Several of the existing tests check for situations involving colored text. I'm a little surprised that none of them catch this case, but I'll make sure to add a test that does. |
3 participants
v710 introduced a regression where wrapped lines (after the first wrap) would get their color removed when scrolling down (off the top of the screen) and then back up. The initial line retains its coloring, but any wrapped lines afterwards get reset to normal.
For instance:
Now, scroll down 3 lines, and back up 3 lines, then you see:
You can reproduce with something like:
and then scroll down and back up.
This appears to be an unintentional regression, because the color is restored to the wrapped lines if you hit CTRL-L or send less a SIGWINCH.
(My use case is I use
less --wordwrap -Ras a viewer/reader with my own ansi 'dark mode' theme, with amber text and other markup. It's worked perfectly in the past, but after updating to v710, this regression appeared and it's pretty jarring when I scroll back up, unfortunately.)I did a git bisect which pointed to f432d2d as the change that introduced the regression.
That commit curiously moved the
loop:label in input.c from after the prewind()/plinestart() calls to just before them. Was that intentional? I haven't studied the code carefully enough to say with any confidence. But it is not explained in the commit message and I wonder if it was accidental.Moving the loop label back to its pre-f432d2d position fixes the color getting removed from wrapped lines regression, and still displays the marks correctly with
-J, according to the reproducer steps in #820.