From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#19945: emacsclient confused by active minibuffer Date: Sun, 06 Dec 2020 15:24:56 +0200 Message-ID: <83v9df9idz.fsf@gnu.org> References: <87360nru5z.fsf@gnus.org> <83czzqgb2g.fsf@gnu.org> <87tut1nbk9.fsf@gnus.org> <83mtyteqq8.fsf@gnu.org> <87v9dfdrfv.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16326"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 19945@debbugs.gnu.org, noe.rubinstein@gmail.com To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 06 14:26:49 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1klu3t-00049t-E0 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 06 Dec 2020 14:26:49 +0100 Original-Received: from localhost ([::1]:55058 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1klu3s-0005G9-2O for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 06 Dec 2020 08:26:48 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49746) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1klu38-0005F7-TE for bug-gnu-emacs@gnu.org; Sun, 06 Dec 2020 08:26:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37633) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1klu38-0002DL-M6 for bug-gnu-emacs@gnu.org; Sun, 06 Dec 2020 08:26:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1klu38-0007Wn-IZ for bug-gnu-emacs@gnu.org; Sun, 06 Dec 2020 08:26:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Dec 2020 13:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19945 X-GNU-PR-Package: emacs Original-Received: via spool by 19945-submit@debbugs.gnu.org id=B19945.160726112828895 (code B ref 19945); Sun, 06 Dec 2020 13:26:02 +0000 Original-Received: (at 19945) by debbugs.gnu.org; 6 Dec 2020 13:25:28 +0000 Original-Received: from localhost ([127.0.0.1]:49179 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1klu2Z-0007Vz-Oq for submit@debbugs.gnu.org; Sun, 06 Dec 2020 08:25:28 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:59748) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1klu2Y-0007Vn-8d for 19945@debbugs.gnu.org; Sun, 06 Dec 2020 08:25:26 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37116) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1klu2S-0001qX-W4; Sun, 06 Dec 2020 08:25:21 -0500 Original-Received: from [176.228.60.248] (port=4357 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1klu2I-000692-At; Sun, 06 Dec 2020 08:25:15 -0500 In-Reply-To: <87v9dfdrfv.fsf@gnus.org> (message from Lars Ingebrigtsen on Sun, 06 Dec 2020 13:55:48 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:195094 Archived-At: > From: Lars Ingebrigtsen > Cc: 19945@debbugs.gnu.org, noe.rubinstein@gmail.com > Date: Sun, 06 Dec 2020 13:55:48 +0100 > > Eli Zaretskii writes: > > > It isn't emacsclient that's doing this. Remember: emacsclient just > > sends a command to Emacs via a socket; processing of that command and > > displaying the results on the frame's display is done by the server, > > i.e. by Emacs. > > > > So it's Emacs that's waiting, probably inside sit_for. > > Well, Emacs is in a recursive minibuffer (since there's an `M-x' in > action), and the server code is ending it when emacsclient talks to it. > > But waits a second first. > > My question was whether this wait is on purpose (to notify the user that > we're ending the M-x), or whether it's a bug. It's neither, AFAIU. It's just that sit_for is not interrupted by the client attempting to connect (like it would by keyboard input, for example). If I'm right, then TRT, IMO, would be to arrange for it to be interrupted in this case. (The wait in this case is to provide echo for the key sequence when the user stops typing for a while, but cease waiting immediately when new input arrives.)