On 24 September 2016 at 22:31, Bart Schaefer <schaefer@brasslantern.com> wrote:
> You're probably interested in getbyte() in zle_main.c, but you might
> also attach with a debugger and put a breakpoint in zhandler so you
> can get a stack trace of where the handler is being called [if it is].
> (Starting the debugger first and running zsh inside it won't work as
> well because the debugger itself will trap the signals).

I've set breakpoint to zhandler, it was called on each Ctrl-C. And
.recursiveedit never exited. Following execution paths I've spotted
crucial places and added debug prints. Luckily it's easy to trigger
".recursiveedit not canceled" and ".rec. cancelled" paths when not in
debugger. Attached is 10-context lines diff. Exit from .recursiveedit
is:

-- Doing break / zle_main.c: errflag: 2, retflag: 0, breaks: 0, exit_pending: 0
-- Got EINTR 1
-- Setting error in zlecore.c

I've also observed that following possible, though rare:

-- Got EINTR 1
-- Setting error in zlecore.c

No reaction on Ctrl-C, i.e. no-exit from .recursiveedit, is:

-- Trying again !errtry / zle_main.c
(now another Ctrl-C)
-- Doing break / zle_main.c: errflag: 2, retflag: 0, breaks: 0, exit_pending: 0
-- Got EINTR 2
-- Setting error in zlecore.c

I will go further into this but apparently zhandler should set errflag?

Best regards,
Sebastian Gniazdowski