kalle olavi niemitalo wrote:
> Jeff King <p...@peff.net> writes:
> > Comments welcome from people using unusual editors (e.g., a script that
> > starts an editor in another window then blocks, waiting for the user to
> > finish).
> I often run a shell in Emacs in X, then start git commit in that
> shell. $EDITOR is emacsclient --current-frame, which asks the
> existing Emacs instance to load the file and waits until I press
> C-x # in Emacs to mark the file done. If I want to abort the
> commit, it is most intuitive to return to the *Shell* buffer in
> Emacs and press C-c C-c (comint-interrupt-subjob) to send SIGINT
> to git from there. (I see that "an empty message aborts the
> commit", and indeed it does, but well, I prefer not to trust such
> a feature if I can instead just interrupt the thing.)
> With pf/editor-ignore-sigint, C-c C-c in the *Shell* buffer kills
> neither git nor the emacsclient started by git. This is not good.
> SIGQUIT from C-c C-\ (comint-quit-subjob) still works though.
when i implemented the change, i wondered if some twisted emacs
workflow would be an issue. ;-) and i almost blocked SIGQUIT as
well -- the two programs i looked at for precedent (CVS and MH) both
block both SIGQUIT and SIGINT when spawning an editor.
but since emacs users must have dealt with CVS for a long time before
dealing with git, how might they have done so?
the existing git behavior is bad for non-emacs users, and git itself
provides an abort-the-operation mechanism (i.e., writing an empty
message), so i'm not convinced your use case invalidates the new
behavior. (though it might spotlight a need for this being prominent
in release notes.)
paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 40.6 degrees)
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html