Re: [BUG] queueing_enabled grows infinitely when in .recursive-edit

[Sebastian Gniazdowski <sgniazdowski@gmail.com>]

On 3 October 2016 at 17:49, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Oct 3, 12:00pm, Sebastian Gniazdowski wrote:
> }
> } On 3 October 2016 at 01:21, Bart Schaefer <schaefer@brasslantern.com> wrote:
> I think that's probably best left up to the person implementing the
> scheduled function.  Also minimally complicated if the code below
> zlecore() doesn't have too many special cases for recursive-edit.

So being in .recursive-edit is detectable from scheduled function? How?

> Indeed, try this:
>
> diff --git a/Src/Zle/zle_main.c b/Src/Zle/zle_main.c
> index 0b3b1fc..04b9357 100644
> --- a/Src/Zle/zle_main.c
> +++ b/Src/Zle/zle_main.c
> @@ -471,7 +471,7 @@ calc_timeout(struct ztmout *tmoutp, long do_keytmout)
>
>             tfdat = (Timedfn)getdata(tfnode);
>             diff = tfdat->when - time(NULL);
> -           if (diff < 0) {
> +           if (diff <= 0) {
>                 /* Already due; call it and rescan. */
>                 tfdat->func();
>                 continue;

It works, I have following debug messages generated after lucky Ctrl-C
issued when in .recursive-edit:

raw_getbyte() - queueing_enabled (0)
CALLING diff[0] queueing_enabled (0)
N-O-T CALLING diff[1] queueing_enabled (0)
-- INIT tmout.tp(2) ZTM_NONE(0) ZTM_KEY(1) / BEGIN RAW_GETBYTE() zle_main.c

So, calc_timeout() returns tmout.tp == 2, which is ZTM_FUNC, and does
that because the diff[0] inside-calc_timeout call of scheduled
function did apparently reschedule – the "N-O-T CALLING" entry,
generated in else{} of if(diff <=0).

Best regards,
Sebastian Gniazdowski