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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Oct 5,  7:31am, Sebastian Gniazdowski wrote:
} Subject: Re: Where to start debugging zle recursive-edit? / Ctrl-C
}
} 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.

For your purposes, the trouble with periodic is that it only executes
right before a prompt.  Unless there's more to what you're saying than
I'm understanding.

} However periodic hook rather suffers too from no-timeout select()?

I wouldn't expect so, no.  It's not related to the select at all.

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

I meant something about scheduling.

} > Either way you'd want to examine $zle_scheduled_events
} 
} Tried accessing the variable from zle widget and no luck

My typo, it's $zsh_scheduled_events.  It's in the documentation for the
sched module.

} 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?

Either open a named pipe file (mknod p filename), or use the zsh/tcp
module as in the example that appears in the documentation.

Another thing I've done quite successfully for a very long time is to
assign to the TMOUT variable and use TRAPALRM() to take some action
(such as update the time in my prompt).  This is close to the same
behavior as sched but uses the alarm() system function so doesn't
rely on zle read timeouts.