A part of the text is temporarily cleared while searching

[vinc17fr]

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 with less 633 under Android/Termux.

To reproduce:

1. Open a text terminal (e.g. xterm or GNOME Terminal) with 32 lines and 80 columns (under Android/Termux, I had 55 lines).
2. Run the following command:

   for i in `seq 999999`
   do echo xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   done | env -u LESS less

3. Type > to go to the end of the text.
4. Type < to go to the beginning of the text.
5. Type /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:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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.

[vinc17fr]

The bug was introduced by commit 96f2bcd131e5bf6da9cc3b8db92b78db31ccf885 for less 624.

[vinc17fr]

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.

[avih]

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.

[gwsw]

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

[gwsw]

Should be fixed in d67f5b0b5cd4c835f4939bd4afd0c17a4917609a in the post659 branch.