Re: Where to start debugging zle recursive-edit? / Ctrl-C

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

On 30 September 2016 at 22:44, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> You may need to find a more aggressive place to reset the timer, such
> as in the zle-line-pre-redraw hook, or else create a wrapper widget
> for recursive-edit.

Was going to do this with periodic hook. Now as 5.3 is fixed I could
say: "Share PERIOD with this plugin, set it to value 6...10, best is
10. And if you really want to own PERIOD, then use latest Zsh".
However periodic hook rather suffers too from no-timeout select()?

Wrapper around recursive-edit would solve Ctrl-C problems, or you
meant something about rescheduling?

> Either way you'd want to examine $zle_scheduled_events to see if the
> timer is still pending, before scheduling it again.

Tried accessing the variable from zle widget and no luck. I must be
doing something wrong as even ack '.*zle.*sched.*eve.*' doesn't return
results.

> Or possibly you could switch from doing this with a timer scheduled
> function to using a "zle -F" handler function.

Cool thing the zle -F, thanks for the tip. It would obviously install
where main symptom of problem occurs, at the select(). But how could I
periodically change state of the FD, without forking background
process for each instance of Zsh?

A half-ready solution is to schedule no-op function 24 hours ahead
(saw something about that maximum schedule time), this should make
calc_timeout() always return ZTM_FUNC. But this requires something
more, as the main scheduled function might still stop running because
of errflag. Maybe this should be done together with periodic hook.
select() would not block (ZTM_FUNC), and periodic hook is maybe immune
to errflag rescheduling-break?

Best regards,
Sebastian Gniazdowski