From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ovidiu Gheorghioiu Newsgroups: gmane.emacs.help Subject: Re: Emacs hangs on current display when the minibuffer is active on another display Date: Thu, 25 Feb 2010 16:28:28 -0800 Message-ID: <1adb6ea1002251628p77f28902nfe1fe77b654119de@mail.gmail.com> References: <1adb6ea0609261909u138ff25fj3cee334a6232ca3b@mail.gmail.com> <1adb6ea0708202154v142e8eb4vb85b6cb65bcd1fdd@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1267156823 19707 80.91.229.12 (26 Feb 2010 04:00:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 26 Feb 2010 04:00:23 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: rms@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Feb 26 05:00:17 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NkrNB-0007NP-AR for geh-help-gnu-emacs@m.gmane.org; Fri, 26 Feb 2010 05:00:17 +0100 Original-Received: from localhost ([127.0.0.1]:38944 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NkrNA-0006Ed-KV for geh-help-gnu-emacs@m.gmane.org; Thu, 25 Feb 2010 23:00:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nko4a-0005yE-TK for help-gnu-emacs@gnu.org; Thu, 25 Feb 2010 19:28:52 -0500 Original-Received: from [140.186.70.92] (port=51837 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nko4Z-0005y6-6B for help-gnu-emacs@gnu.org; Thu, 25 Feb 2010 19:28:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nko4Y-00016k-C1 for help-gnu-emacs@gnu.org; Thu, 25 Feb 2010 19:28:51 -0500 Original-Received: from mail-iw0-f203.google.com ([209.85.223.203]:45640) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nko4Y-00016b-8V; Thu, 25 Feb 2010 19:28:50 -0500 Original-Received: by iwn41 with SMTP id 41so5825892iwn.27 for ; Thu, 25 Feb 2010 16:28:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=fPF1A61y8p0apCwDm5xySP/7ZCGn4v9o5GTORE1x71M=; b=FNNwikMOvoxjO+xdjREVkEGJ+qwesrUqEFfGOArrsfZrjKkttNbwkU35rzXvZXtEK0 TXoDc70dVwJM5WD8nF6aTCSL9MQKoMy5ajr9xRmJpQIdG9WW742Ewlh4WhS5nm7ArFWQ 2gWUjVCJKK/e/6lsxvorrHH8nlYXfCTWDrXVs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=fYTY33VIcHY2vUs00bpTcWSz2cv9nzdj71b1nDeskhIM3o6nu5O18Mg/tQP39GKka+ VG1T+rLUk6QX4HI3y2TOEquchYx/oG99QkzyCQFpk/DJHJ0ZoCwWtTMCP6pgno1XB4qn Ms0TTTfEIDLY21iSf5NxP2Js+eO/vT2eQ7B7Q= Original-Received: by 10.231.154.213 with SMTP id p21mr179019ibw.42.1267144128726; Thu, 25 Feb 2010 16:28:48 -0800 (PST) In-Reply-To: <1adb6ea0708202154v142e8eb4vb85b6cb65bcd1fdd@mail.gmail.com> X-Google-Sender-Auth: 50dea4822b9b2464 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Mailman-Approved-At: Thu, 25 Feb 2010 22:59:50 -0500 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:72150 Archived-At: FYI I've found a workaround for this old problem: I evaluate '(abort-recursive-edit)' with gnuclient / emacsclient. Tested on emacs 23.1.1 and 22.1.1 (both of which still exhibit the minibuffer-input-blocks-other-Xdisplay problem). This aborts the minibuffer prompt, and lets me use emacs on the other display. This is good enough for me. Regards, Ovy > On Mon, Aug 20, 2007 at 8:54 PM, Ovidiu Gheorghioiu wr= ote: > Is there an eval forn that would cause emacs to exit this loop? > > I can do gnuclient -eval from the display where Emacs is > non-functional. I've tried (keyboard-quit) and > (minibuffer-keyboard-quit) but that didn't work. Finally I did (setq > quit-flag t) with the -- foreseeable I guess -- result that Emacs quit > entirely. So maybe there is some hope. A workaround involving -eval > (something) would be perfectly acceptable for me. > > Regards, > Ovy > > On 9/27/06, Richard Stallman wrote: >> =A0 =A0 If I leave the emacs on one >> =A0 =A0 display with the minibuffer active, emacs on the other display d= oes >> =A0 =A0 not respond to anything until the minibuffer input is resolved (= input >> =A0 =A0 entered, or quit). >> >> It is nearly impossible to fix this without making Emacs >> multi-threaded. =A0I hope that will be done some day, but I >> don't know if anyone is working on it. >> >> >