bug#19945: emacsclient confused by active minibuffer

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 19945@debbugs.gnu.org,  noe.rubinstein@gmail.com
> Date: Mon, 07 Dec 2020 14:17:12 +0100
> 
> Eli Zaretskii <eliz@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?