From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Weird behavior and crash with X and TTY frame Date: Sun, 07 Apr 2013 18:36:10 +0300 Message-ID: <83li8ucpzp.fsf@gnu.org> References: <51601D0E.4050507@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1365348994 27447 80.91.229.3 (7 Apr 2013 15:36:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Apr 2013 15:36:34 +0000 (UTC) Cc: dmantipov@yandex.ru, emacs-devel@gnu.org To: Jan =?iso-8859-1?Q?Dj=E4rv?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 07 17:36:37 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UOrdy-0006Mp-Hf for ged-emacs-devel@m.gmane.org; Sun, 07 Apr 2013 17:36:34 +0200 Original-Received: from localhost ([::1]:44548 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UOrdx-0007Oh-Tp for ged-emacs-devel@m.gmane.org; Sun, 07 Apr 2013 11:36:33 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43754) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UOrdp-0007OU-Gc for emacs-devel@gnu.org; Sun, 07 Apr 2013 11:36:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UOrdl-0005ph-9X for emacs-devel@gnu.org; Sun, 07 Apr 2013 11:36:25 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:53858) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UOrdl-0005pB-08 for emacs-devel@gnu.org; Sun, 07 Apr 2013 11:36:21 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MKW00M005SDPC00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Sun, 07 Apr 2013 18:36:03 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MKW00MCG602K370@a-mtaout21.012.net.il>; Sun, 07 Apr 2013 18:36:03 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:158752 Archived-At: > From: Jan Dj=E4rv > Date: Sun, 7 Apr 2013 14:06:46 +0200 > Cc: Emacs development discussions >=20 > This is something Emacs can't handle. It is because how the lisp a= nd event loop interracts. >=20 > When you do (x-popup-dialog t '("Test" ("yes" . 1))), a Lisp return= value is expected back to the Lisp code. So Emacs does not execute = any more Lisp, until the dialog is popped down. > The popup is shown by a loop that just processes X events (x_menu_w= ait_for_event). > When you switch frame and do C-g C-g, the "normal" stuff does not h= appen, because Lisp is not executed. >=20 > This would be solvable if we had an independent Lisp loop per termi= nal, but it is not so. > There is only one Lisp loop, shared by all frames/terminals, and if= one frame/terminal suspends the loop, it is suspended for all frames= /terminals. Actually, this isn't a problem at all. It's a (very old) feature, called "emergency escape": when Emacs is stuck in some prolonged computation or loop, typing C-g twice on a TTY invokes this behavior, whereby the TTY is first suspended, to get the user a chance to investigate what's wrong (in case there are no other windows to do that, but just a single console), and then, after Emacs is resumed, i= t offers to dump core, so that the problem could be looked into with a debugger. See the node "Emergency Escape" in the user manual. The only misfeature in this scenario is that the "loop" in this case is processing X events for a dialog we popped up ourselves. FWIW, I don't see any particular problem here. To make things more explicit, perhaps x-popup-dialog should set some variable that handle_interrupt could test and display some descriptive message in the echo area, so the user would know that the X frame is in a modal state.