Zsh Mailing List Archive
Messages sorted by:
Re: Where to start debugging zle recursive-edit? / Ctrl-C
On 5 October 2016 at 08:14, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> 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.
Had some obstacles to use the precmd but really not recalling them now.
> } Wrapper around recursive-edit would solve Ctrl-C problems, or you
> } meant something about rescheduling?
> I meant something about scheduling.
Hmm, could you reveal? I thought about trapping INT when detected that
in .recursive-edit, but directly that's "Ctrl-C problems" stuff
> } > 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.
So no need to parse sched output at all, as I once wrote
> Either open a named pipe file (mknod p filename), or use the zsh/tcp
> module as in the example that appears in the documentation.
That are rather heavy-implementation things
> 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.
Thanks for info that this trap doesn't cause problems, I would be
definitely anxious about using it (expecting things like e.g. the
pick-up of z-sy-h state, but that's maybe plain simple lack of opt
localoptions), don't want to serve users heavy-implementation stuff,
but if the trap is proven to be robust, then..
Messages sorted by: