top: fix a bug from when 'Ctrl' window was made sticky

In the patch referenced below the bottom 'Ctrl' window
was made to remain until it was dismissed by the user.

As such, it required abandoning a 'Cap_nl_clreos' used
when all the terminal rows had not been drawn. Instead
each line had to be cleared individually until the row
reserved for that 'Ctrl' window area had been reached.

Unfortunately, while a 'Cap_nl_clreos' didn't create a
problem for 'batch' mode, a 'Cap_clr_eol' used instead
yielded an unending loop if those rows were limitless.

So, now we will only clear that area when top isn't in
'batch' mode (which should have always been the case).

Reference(s):
. May, 2022 - bottom window made sticky
commit 0f2a755b0b2754fca79545984e25ec52f4ae4444

Signed-off-by: Jim Warner <james.warner@comcast.net>

diff --git a/top/top.c b/top/top.c
index 2bc7d45e67ff220691c0f37cd96e850dbb09a108..9f7477a0619a9a8cec38244ffeb67e4c3c8038f2 100644 (file)
--- a/top/top.c
+++ b/top/top.c
@@ -6833,7 +6833,7 @@ static void frame_make (void) {
 
    /* clear to end-of-screen - critical if last window is 'idleps off'
       (main loop must iterate such that we're always called before sleep) */
-   if (scrlins < Max_lines) {
+   if (!Batch && scrlins < Max_lines) {
       for (i = scrlins + Msg_row + 1; i < SCREEN_ROWS; i++) {
          putp(tg2(0, i));
          putp(Cap_clr_eol);