Open vinc17fr opened 2 months ago
The bug was introduced by commit 96f2bcd131e5bf6da9cc3b8db92b78db31ccf885 for less
624.
That's the clear_eol()
in https://github.com/gwsw/less/commit/96f2bcd131e5bf6da9cc3b8db92b78db31ccf885#diff-1c17c7f306ab222e2dfac1b6aa481d6ffe26a8a743a0f5091379da2de9668cf0R276 that triggers the issue. This is also because the cursor is somewhere in the middle of the text, and I'm wondering whether this is correct: I would expect the cursor to be on the same line as the prompt.
To reproduce: ...
For what it's worth, I can't reproduce this on windows, with a (windows) terminal size of 80 columns and either 32 lines or 55 lines.
I.e. after >
, <
, /z<enter>
and until it displays the not-found message, the content is intact.
However, I can reproduce it on linux in xterm with size 80x32.
Seems like there is a flush() missing somewhere. It needs to be called to write the buffered terminal data before a long pause, like in a search. This patch fixes it, but it may not be the best fix. I'll look into this some more.
--- a/search.c
+++ b/search.c
@@ -296,6 +296,7 @@ public void repaint_hilite(lbool on)
}
overlay_header();
lower_left();
+flush();
hide_hilite = save_hide_hilite;
}
#endif
Should be fixed in d67f5b0b5cd4c835f4939bd4afd0c17a4917609a in the post659 branch.
With some terminal sizes, a part of the text is temporarily cleared while searching.
This bug reproducible with the
less
643-1 Debian/unstable package and withless
633 under Android/Termux.To reproduce:
>
to go to the end of the text.<
to go to the beginning of the text./z
then [Enter] to search for "z" (something that does not appear in the text).Result: During the search, a part of the text is cleared. For instance, with a 32-line terminal:
Note: the goal of the high number of lines in the full text is to ensure that the search takes enough time to make the issue appear. After "Pattern not found (press RETURN)" is output, the text is restored.