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

[Sebastian Gniazdowski <sgniazdowski@gmail.com>]

On 5 October 2016 at 20:31, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Oct 5, 12:27pm, Sebastian Gniazdowski wrote:
> } 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

Thanks, was about to search for a way to interrupt recursive-edit.

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

Binaries are cool if they are created using small, portable C code.
Compilation is fast, without "strcasestr() exists?" problems, and so
many such C programs out there, expecting them to compile everywhere
after I compiled util-linux/flock on FreeBSD and OS X. Tried to
convert program "highlight" to return region_highlight and it was much
worse because it's large C++ code without configure script. Thinking
about what's actually heavy and what's not made me realize that I
might refuse a good solution, after all it's only one *period_passed
function that needs to be called. Will check this soon.

Best regards,
Sebastian Gniazdowski