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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Oct 5, 12:27pm, Sebastian Gniazdowski wrote:
}
} > } Wrapper around recursive-edit would solve Ctrl-C problems, or you
} > } meant something about rescheduling?
} >
} > I meant something about scheduling.
} 
} Hmm, could you reveal?

This was proposed before we'd identified the problem with the signal
queue getting too deep, so may not be helpful any more; but the idea
is that since ^C returns you to the caller of recursive-edit, this
means precmd is not run.  So if you need to reset something that is
normally handled in precmd, you should include that part of precmd
in the wrapper, calling it after "zle .recursive-edit" returns.

} I thought about trapping INT when detected that
} in .recursive-edit, but directly that's "Ctrl-C problems" stuff

trap 'zle && zle .send-break' INT # might be helpful with localtraps

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

Is having a named pipe file really that much heavier than having the
shared text file plus that external flocking app to synchronize the
access to it?