GNU bug report logs - #19945
emacsclient confused by active minibuffer

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 19945 <at> debbugs.gnu.org, noe.rubinstein <at> gmail.com
Subject: bug#19945: emacsclient confused by active minibuffer
Date: Sun, 06 Dec 2020 15:24:56 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 19945 <at> debbugs.gnu.org,  noe.rubinstein <at> gmail.com
> Date: Sun, 06 Dec 2020 13:55:48 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> 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.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.