Re: PATCH: edit-command-line: disable `monitor' option locally

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mar 17,  6:56pm, Frank Terbeck wrote:
} Bart Schaefer wrote:
} > I suspect that in your case the entire edit-command-line function is
} > stopped, so rm -f / zle send-break never happens until after you bring
} > it into the foreground again, but I don't know why it differs for me.
} 
} Here it is:
} [snip]
} % zsh -f
} zsh% cat t
} autoload -Uz edit-command-line
} zle -N edit-command-line
} bindkey $'\ee' edit-command-line
} zsh% source ./t
} zsh% echo foobar+edit-command-line:11> local 'tmpfile=/tmp/zshecl16683'
} +edit-command-line:13> print -R - 'echo foobar'
} +edit-command-line:15> vim /tmp/zshecl16683
} zsh: suspended  

So, exactly as I thought, your entire shell function is being stopped
at this point.  This does not happen for me.  In fact, with VISUAL=less,
it becomes impossible for me to stop the "editor" AT ALL, even though
under normal circumstances I can suspend less normally.  Further, if
I set VISUAL=emacs so that it opens in a new window, I can't suspend
emacs by typing ^Z into the shell window.  This is with the ORIGINAL
edit-command-line, NOT with the patch to add no_monitor.

So AFAICT, for me, the only reason the ^Z is being handled at all is
because vim is handling it internally; monitor only affects whether
the shell does the right thing when vim does its own suspend.

If I add an   stty < /dev/tty >& /dev/tty   to edit-command-line, I
find that my susp character has been set to undef:

torch% VISUAL=cat
torch% +edit-command-line:2> local 'tmpfile=/tmp/zshecl26906'
+edit-command-line:3> print -R - ''
+edit-command-line:5> stty
speed 38400 baud; line = 0;
quit = <undef>; susp = <undef>; lnext = <undef>; flush = <undef>;
min = 1; time = 0;
-brkint inlcr -imaxbel
-icanon -echo
+edit-command-line:6> cat /tmp/zshecl26906

+edit-command-line:7> print -Rz - ''
+edit-command-line:8> rm -f /tmp/zshecl26906
+edit-command-line:9> zle send-break

torch% 

So zsh apparently is already trying to do the right thing.

What we need to figure out is why the suspend character has not been
successfully cleared for you (and for the people reporting this bug).
I believe it's zsetterm() in Src/Zle/zle_main.c that clears the VSUSP
field in the ttyinfo structure in my case.

Of course that doesn't help with vim handling the keystroke on its
own and pretending it got a signal that it never got.

--