jeff wrote: > On Wed, Nov 21, 2012 at 10:27:50AM +0100, Krzysztof Mazur wrote: > > > > > * pf/editor-ignore-sigint (2012-11-11) 5 commits > > > > > > > > Avoid confusing cases where the user hits Ctrl-C while in the editor > > > > session, not realizing git will receive the signal. Since most editors > > > > will take over the terminal and will block SIGINT, this is not likely > > > > to confuse anyone. > > > > > > > > Some people raised issues with emacsclient, which are addressed by this > > > > re-roll. It should probably also handle SIGQUIT, and there were a > > > > handful of other review comments. > > > > > > > > Anybody interested in moving this forward? > > > > > > i started this, but then jeff took it and ran with it and made it > > > right. i think the remaining changes are small -- if jeff would > > > prefer, i can probably finish it. (but i won't guarantee not to > > > mess up the "From:" lines. :-) > > > > > > > I'm also interested. I sometimes use ":r !command" in vim, so far I never > > needed to use Ctrl-C, but maybe in future. > > > > The SIGINT part seems to be finished, we need to decide what about SIGQUIT. > > My plan was to just add in SIGQUIT[1] alongside SIGINT (and I think > there may have been one or two other minor comments in response to the > series). I am on vacation this week, but can revisit it next week. If > somebody wants to re-roll it in the meantime, that would be fine with > me. > > -Peff > > [1] Given the core-dumping behavior of SIGQUIT, I suspect it is not > nearly as widely used as SIGINT, but it sounds more like the > principle of least surprise to treat them the same. i see no real point in treating them the same -- as you suggest, one would only use SIGQUIT if SIGINT didn't work, and then you'd want them to be treated differently. so i'd be happy with the current code in that regard. i think krzysiek said that since editors usually catch SIGQUIT, git should kill the editor when receiving SIGQUIT, essentially translating the SIGQUIT to SIGTERM for the editor. (please correct me if i misunderstood.) since well-behaved editors will die quickly anyway (they get EIO on their next read from stdin), i'm not sure there's a compelling reason for that extra step. but i have no real objection to that behavior if others think it's right -- there's certainly logic in saying that if git dies it should ensure the editor does too. (i'm away for the rest of the week also.) paul =--------------------- paul fox, pgf@xxxxxxxxxxxxxxxxxxxx (arlington, ma, where it's 44.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