From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Ami Fischman" Newsgroups: gmane.emacs.devel Subject: Re: poor handling of multiple C-g with multi-tty (apparent hangs) Date: Mon, 15 Sep 2008 20:33:13 -0700 Message-ID: <9aa0cfde0809152033m4667f51an17a45eb22d3deedd@mail.gmail.com> References: <48a85bf8.02a6420a.410f.ffffc5a1MFETCHER_ADDED@google.com> <9aa0cfde0809151600h6d61c248g3e801ccc3d363cc2@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1221536008 4371 80.91.229.12 (16 Sep 2008 03:33:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Sep 2008 03:33:28 +0000 (UTC) Cc: cyd@stupidchicken.com, emacs-devel@gnu.org To: "Eli Zaretskii" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 16 05:34:24 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KfRKa-00066K-GQ for ged-emacs-devel@m.gmane.org; Tue, 16 Sep 2008 05:34:24 +0200 Original-Received: from localhost ([127.0.0.1]:49848 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KfRJZ-0007sg-6d for ged-emacs-devel@m.gmane.org; Mon, 15 Sep 2008 23:33:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KfRJU-0007sQ-NU for emacs-devel@gnu.org; Mon, 15 Sep 2008 23:33:16 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KfRJT-0007s9-4i for emacs-devel@gnu.org; Mon, 15 Sep 2008 23:33:16 -0400 Original-Received: from [199.232.76.173] (port=46364 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KfRJT-0007s6-2e for emacs-devel@gnu.org; Mon, 15 Sep 2008 23:33:15 -0400 Original-Received: from wf-out-1314.google.com ([209.85.200.175]:59482) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KfRJS-0005gm-Rj for emacs-devel@gnu.org; Mon, 15 Sep 2008 23:33:15 -0400 Original-Received: by wf-out-1314.google.com with SMTP id 28so2385627wfc.24 for ; Mon, 15 Sep 2008 20:33:13 -0700 (PDT) Original-Received: by 10.142.192.11 with SMTP id p11mr165580wff.111.1221535993492; Mon, 15 Sep 2008 20:33:13 -0700 (PDT) Original-Received: by 10.143.11.8 with HTTP; Mon, 15 Sep 2008 20:33:13 -0700 (PDT) In-Reply-To: Content-Disposition: inline X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:103896 Archived-At: 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 wrote: >> Date: Mon, 15 Sep 2008 16:00:39 -0700 >> From: "Ami Fischman" >> Cc: emacs-devel@gnu.org >> >> On Mon, Aug 11, 2008 at 10:40 AM, Chong Yidong wrote: >> >> > "Ami Fischman" 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? >