I've been having a rather strange problem using manual hunk edit mode (`git add -p`, e) and emacs together. It seems every time I hit ^G inside of emacs in this one circumstance, the entire process instantly shuts down, both emacs and `git add`, and it doesn't even give emacs a chance to clean up the terminal, so I'm left with garbage across my display (the remains of the emacs window) and the terminal settings are screwed up enough that I have to close and reopen it (even `reset` doesn't fix everything). Has anybody else seen this, and if so, do you know what's going on? I cannot reproduce this with emacs outside of `git add -p`, and I cannot reproduce this with vim even inside of `git add -p`.

-Kevin Ballard--

[ message continues ]

Is there some way to get a dump of the environment that emacs is seeing?
If we have that it will be easier to tell if this is an emacs problem or
a git problem.
-- 
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59

--

[ message continues ]

I've been investigating this on the emacs side as well. At the moment, my suspicion is that ^G causes emacs to trigger (keyboard-quit), but at the same time the surrounding environment (e.g. git) is sending a SIGINT to emacs, which normally acts like ^G but in this case may be triggering the emergency exit mode of emacs. Is there some reason that the interactive add would be sending SIGINT to emacs when I type ^G?

-Kevin Ballard--

[ message continues ]

If you are using text mode (-nw) then Emacs redefines the INTR character
of the terminal to ^G.  On the other hand it should also put itself into
its own process group, so the parent should not receive the terminal
signals.  And this is what happens here when I try it.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--

[ message continues ]

I am indeed using text mode. And when I test, invoking `emacs` directly gives it its on process group, but invoking emacs from `git add -p`+e doesn't.

kevin@Brandybuck:~> ps -jp 34581 34540
USER    PID  PPID  PGID   SESS JOBC STAT   TT       TIME COMMAND
kevin 34540 34539 34538 7d29d68    1 S+   s001    0:00.08 /usr/bin/perl /usr/local/libexec/git-core/git-add--interactive --
kevin 34581 34540 34538 7d29d68    1 S+   s001    0:00.61 /usr/bin/emacs /Users/kevin/Dev/Work/Standard9/inkling-ipad/.git/

Any idea why this would be?

-Kevin Ballard--

[ message continues ]

Aside from this bug you might want to check out magit.el, it's a much
nicer hunk edit more for Emacs than running git add -p in an Emacs
terminal is.
--

[ message continues ]

Except I don't run it in an emacs terminal. I run it in my regular terminal, and only launch emacs when I need to in order to edit a hunk or whatnot.

BTW, it also appears that this happens in the normal `git commit` editor as well, I just hadn't noticed before since I rarely need to type ^G when writing a commit message.

-Kevin Ballard--

[ message continues ]

Yup, for that particular problem, magit is, well, like magic :)

-miles

-- 
Pray, v. To ask that the laws of the universe be annulled in behalf of a
single petitioner confessedly unworthy.
--

[ message continues ]

I tested out magit, and didn't particularly like it. First off, it seems to be throwing an error when I invoke magit-status, at least if there's no changes. I don't know if this is related to the fact that my emacs is only 22.1, but magit itself doesn't document any required version of emacs. Secondly, when there is a change, the coloration is really hard to read, and the navigation is quite poor as well (and I didn't find anything to make it better in the cheatsheet). And it's far slower than just using `git add -p` and only dropping into emacs occasionally for manual hunk edits.

I'm still very much interested in finding a solution to why ^G kills emacs when it's invoked by git. As I said earlier, it appears that emacs shares the same process group with the perl process that called it, even though Andreas Schwab says it puts itself into its own process group and invoking emacs from the shell does just that. Does anyone know why this might be happening?

-Kevin Ballard--

[ message continues ]