Manual hunk edit mode + emacs + ^G == garbage

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

On Wed, 2010-10-13 at 14:37 -0700, Kevin Ballard wrote:

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.

On Oct 13, 2010, at 2:48 PM, Drew Northup wrote:

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

Kevin Ballard <kevin@sb.org> writes:

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.

On Oct 13, 2010, at 3:40 PM, Andreas Schwab wrote:

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

On Wed, Oct 13, 2010 at 21:37, Kevin Ballard <kevin@sb.org> wrote:

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.

On Oct 14, 2010, at 2:37 AM, Ævar Arnfjörð Bjarmason wrote:

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

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

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

-miles

On Oct 14, 2010, at 2:51 AM, Miles Bader wrote:

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

Kevin Ballard <kevin <at> sb.org> writes:

Kevin,

I was having the same problem you described on Mac OS X Lion and found this old thread. A workaround that works for me is:

~/bin/emacs.sh:

#!/bin/bash -i

emacs "$@"

-- cut --

git config --global core.editor ~/bin/emacs.sh

Matt