bug#19945: emacsclient confused by active minibuffer

[Lars Ingebrigtsen]

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.

The user hits

`M-x'

which enters a recursive edit, and the "M-x" is displayed immediately.
Then, sometime much later, the user says "emacsclient -nw".  Then there
is a one-second delay, and then the Emacs server filter executes the
actions the client asked for.

Now, the recursive edit is exited by `server-goto-toplevel', but
instrumenting all of this (i.e., the server filter function) is giving
me inconsistent results -- that is, I can't actually pinpoint where in
the code the wait is happening...  perhaps because some redisplay is
inhibited somewhere?  I'm not sure; it's somewhat frustrating...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no