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

[Bart Schaefer <schaefer@brasslantern.com>]

On Oct 3, 12:00pm, Sebastian Gniazdowski wrote:
} 
} On 3 October 2016 at 01:21, Bart Schaefer <schaefer@brasslantern.com> wrote:
} >
} > The first is that recursiveedit() calls zlecore() which calls
} > getkeycmd() which cascades into raw_getbyte() with do_keytmout = 0
} > which in some circumstances means that raw_getbyte() effectively
} > does a blocking read on its first call and only runs the sched
} > after a key is pressed.
} 
} It could be either way, if this is to be resolved. I mean, stopping
} sched when in .recursive-edit has some, if not total sense. It's like
} if user would be in an application.

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.

On Oct 3,  1:55pm, Sebastian Gniazdowski wrote:
}
} raw_getbyte() can return with ZTM_NONE while there are scheduled
} functions, often after Ctrl-C in .recursive-edit.
}  [...]
} 
} It looks like calc_timeout handles diff < 0 and diff > 0 but not diff
} == 0?

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;