From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: lorentey@elte.hu (=?iso-8859-2?Q?L=F5rentey_K=E1roly?=) Newsgroups: gmane.emacs.multi-tty,gmane.emacs.devel Subject: Re: Emacs routinely gets stuck in single_kboard mode Date: Sun, 11 Jul 2004 03:29:49 +0200 Sender: multi-tty-bounces@lists.fnord.hu Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1089509499 2118 80.91.224.253 (11 Jul 2004 01:31:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 11 Jul 2004 01:31:39 +0000 (UTC) Cc: multi-tty@lists.fnord.hu, emacs-devel@gnu.org Original-X-From: multi-tty-bounces@lists.fnord.hu Sun Jul 11 03:31:31 2004 Return-path: Original-Received: from ninsei.hu ([212.92.23.158] helo=chatsubo.ninsei.hu) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BjTBe-0003d7-00 for ; Sun, 11 Jul 2004 03:31:31 +0200 Original-Received: from [127.0.0.1] (nixon [127.0.0.1]) by chatsubo.ninsei.hu (Postfix) with ESMTP id 0926F1AC8F; Sun, 11 Jul 2004 03:31:11 +0200 (CEST) Original-Received: from mx2.elte.hu (mx2.elte.hu [157.181.151.9]) by chatsubo.ninsei.hu (Postfix) with ESMTP id 7C6701AC8C for ; Sun, 11 Jul 2004 03:31:09 +0200 (CEST) Original-Received: from mailbox1.caesar.elte.hu (mailbox1.caesar.elte.hu [157.181.151.157]) by mx2.elte.hu (Postfix) with ESMTP id 7DF59154EC5; Sun, 11 Jul 2004 03:26:39 +0200 (CEST) Original-Received: from eris (line-70-210.dial.freestart.hu [213.197.70.210]) by mailbox1.caesar.elte.hu (Postfix) with ESMTP id 863BBA00E320; Sun, 11 Jul 2004 03:29:56 +0200 (CEST) Original-Received: by eris (Postfix, from userid 1000) id 16C9647C52; Sun, 11 Jul 2004 03:29:49 +0200 (CEST) Original-To: Richard Stallman In-Reply-To: (Richard Stallman's message of "Sun, 13 Jun 2004 17:49:20 -0400") User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) X-ELTE-SpamVersion: MailScanner 4.31.6-itk1 (ELTE 1.2) SpamAssassin 2.63 ClamAV 0.73 X-ELTE-VirusStatus: clean X-ELTE-SpamCheck: no X-ELTE-SpamCheck-Details: score=2.646, required 5.9, RCVD_IN_DYNABLOCK 2.55, RCVD_IN_SORBS 0.10 X-ELTE-SpamLevel: ss X-ELTE-SpamScore: 2 X-BeenThere: multi-tty@lists.fnord.hu X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions of multiple tty support in Emacs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multi-tty-bounces@lists.fnord.hu Xref: main.gmane.org gmane.emacs.multi-tty:15 gmane.emacs.devel:25571 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25571 Sorry for the long response time! Richard Stallman writes: > A possible third bug (and a definite inconvenience) is that enterin= g a > recursive edit (M-x recursive-edit) or a debug session like above s= ets > single_kboard. Pressing C-g unfreezes the other keyboards without > exiting the recursion, with no apparent bad side effects. The bug = is > either that the displays are frozen unnecessarily, or that C-g shou= ld > not break out of single_kboard in this case. > > A recursive edit or debug session must set single_kboard, > because the environment of the recursive edit or debug session > would otherwise be imposed on all the other terminals. I see, but if there are multiple frames, then that recursive environment is imposed on them, and AFAICS in that case this only results in some small inconveniences that are easy to work around. I have only seen exactly these same effects when C-g exited single_kboard, no new bugs. So why are multiple displays different from frames in this particular case? Did I miss some important edge case in the implementation? Input event processing in Emacs is still a hazy area for me. By the way, the biggest such inconvenience I have found is a small wrinkle that appears when I forget about a minibuffer prompt and switch to another frame. It is reproducible in the CVS trunk, too: emacs -q --eval '(setq enable-recursive-minibuffers t)' C-x 5 2 C-x C-f M-x (Note that the cursor in the first frame returns to the *scratch* buffer's window) C-g At this point, the C-x C-f prompt is still there in the minibuffer, but the minibuffer window is active in neither frame. What is more, pressing C-x o to return to the minibuffer to finish (or cancel) the command only works in the second frame, not in the first where it was initiated. (I seem to remember that Emacs 19/20 behaved more intuitively, but I am not able to test that now.) > This is part of the reason why we discourage use of recursive edit. > It cannot be avoided unless we implement multi-threading in Emacs. > > Does this fix that bug? Yes, the patch does prevent C-g from unfreezing the other displays. > *** keyboard.c 11 Jun 2004 21:54:28 -0400 1.778 > --- keyboard.c 13 Jun 2004 16:19:43 -0400=09 > *************** > *** 1158,1164 **** > =20 > Vinhibit_quit =3D Qnil; > #ifdef MULTI_KBOARD > ! any_kboard_state (); > #endif > =20 > return make_number (0); > --- 1158,1165 ---- > =20 > Vinhibit_quit =3D Qnil; > #ifdef MULTI_KBOARD > ! if (command_loop_level =3D=3D 0 && minibuf_level =3D=3D 0) > ! any_kboard_state (); > #endif > =20 > return make_number (0); --=20 K=E1roly