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

Previous Next

Full log

Message #29 received at 19945 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#19945: emacsclient confused by active minibuffer
Date: Mon, 07 Dec 2020 19:41:01 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 19945 <at> debbugs.gnu.org,  noe.rubinstein <at> gmail.com
> Date: Mon, 07 Dec 2020 14:17:12 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> 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.)
> 
> I'm not sure what sit-for you're referring to here.

Not sit-for, sit_for.  This one:

	  tem0 = sit_for (Vecho_keystrokes, 1, 1);

You did say we are stuck there for the duration of that 1 sec, didn't
you?  So I'm saying that the problem might be that the connection from
the client doesn't stop sit_for's waiting, and one possible solution
is to arrange it to do so.

Does that make sense?

Previous Next

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