Re: poor handling of multiple C-g with multi-tty (apparent hangs)

[Ami Fischman]

The problem with the current code is that I can start an emacs session
in a tty at work, go home, use emacsclient to start an X frame (served
by that tty emacs at work, displayed on my X server at home), hit C-g
twice at an inopportune time, and be left with an unusable emacs,
because the tty frame has dropped back to the shell at work, but I'm
at home and unable to type the fg RET RET RET incantation into that
shell to get emacs back into the foreground.

The generalization of this scenario is that dropping an emacs process
to its invoking shell's tty is only a good idea if you're certain that
the user can reach that shell.

-a

On Mon, Sep 15, 2008 at 8:16 PM, Eli Zaretskii <address@hidden> wrote:
>> Date: Mon, 15 Sep 2008 16:00:39 -0700
>> From: "Ami Fischman" <address@hidden>
>> Cc: address@hidden
>>
>> On Mon, Aug 11, 2008 at 10:40 AM, Chong Yidong <address@hidden>wrote:
>>
>> > "Ami Fischman" <address@hidden> writes:
>> >
>> > > Emacs has code to deal with C-g being entered while a quit is already
>> > > in progress, meant to suspend emacs and drop the user to the superior
>> > > shell or debugger (see section 59.7 Emergency Escape of the emacs
>> > > info).  This is done if emacs believes it's a good idea, which
>> > > criteria includes "running in tty mode".  Unfortunately this was never
>> > > updated to work correctly with the multi-tty patch.
>> >
>> > Thanks for pointing this out.
>> >
>> > IIUC, the "emergency C-g" behavior is geared towards the traditional
>> > setup where there's only one text-only terminal available.  There, the
>> > emergency C-g is the only way to drop back to the shell if Emacs gets
>> > stuck.
>> >
>> > It's disabled for graphical terminals because there, you can open up a
>> > separate terminal to kill/suspend the Emacs process.
>> >
>> > This implies that we should disable the emergency C-g if Emacs is
>> > running on more than one terminal, as in the following patch.
>
> I don't understand the problem(s) with the current code, nor the
> reason why the emergency shutdown should only work when there's only
> one terminal.  Perhaps the intent was to check if some of the other
> terminals are non-tty's?  Could someone explain the problem and the
> reasoning for the proposed solution?
>