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