Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



kalle olavi niemitalo wrote:
 > Jeff King <peff@xxxxxxxx> 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, pgf@xxxxxxxxxxxxxxxxxxxx (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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]