Signal handlers and Re: Behaviour of zle list-choices

Signal handlers and Re: Behaviour of zle list-choices

[Bart Schaefer]

On Feb 28,  7:56am, Joe M wrote:
}
} > type -a -f TRAPINT
} > TRAPINT () {
} >         ft_zle_state[minibuffer]=no
} >         ft-psvx-default
} >         zle reset-prompt 2> /dev/null
} >         return 127
} > }
} 
} Thanks for your suggestion. Removing the above TRAPINT fixed the
} issue that I am noticing.

OK, that helps.  The problem is with calling reset-prompt (really,
with calling redisplay, which is implied by reset-prompt) from the
signal handler.  The change to resetneeded and clearflag during the
handler causes ZLE to attempt twice to erase the list and move the
cursor back to the start of the prompt, which ends up moving too far
(though only erasing the list once, oddly enough).  It's as though
ZLE gets confused about the state of ALWAYS_LAST_PROMPT.

The following appears to fix it, though I only vaguely understand why.
Anyone care to shed some additional light before this gets committed?

diff --git a/Src/Zle/zle_refresh.c b/Src/Zle/zle_refresh.c
index 7e4f328..aca676a 100644
--- a/Src/Zle/zle_refresh.c
+++ b/Src/Zle/zle_refresh.c
@@ -2435,8 +2435,8 @@ redisplay(UNUSED(char **args))
     moveto(0, 0);
     zputc(&zr_cr);		/* extra care */
     tc_upcurs(lprompth - 1);
-    resetneeded = 1;
-    clearflag = 0;
+    resetneeded = !showinglist;
+    clearflag = showinglist;
     return 0;
 }