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

Previous Next

Full log

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.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 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.

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

Previous Next

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