[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19945: emacsclient confused by active minibuffer
From: |
Lars Ingebrigtsen |
Subject: |
bug#19945: emacsclient confused by active minibuffer |
Date: |
Sun, 06 Dec 2020 13:55:48 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Eli Zaretskii <eliz@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.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
- bug#19945: emacsclient confused by active minibuffer, Lars Ingebrigtsen, 2020/12/03
- bug#19945: emacsclient confused by active minibuffer, Eli Zaretskii, 2020/12/03
- bug#19945: emacsclient confused by active minibuffer, Lars Ingebrigtsen, 2020/12/04
- bug#19945: emacsclient confused by active minibuffer, Eli Zaretskii, 2020/12/04
- bug#19945: emacsclient confused by active minibuffer,
Lars Ingebrigtsen <=
- bug#19945: emacsclient confused by active minibuffer, Eli Zaretskii, 2020/12/06
- bug#19945: emacsclient confused by active minibuffer, Lars Ingebrigtsen, 2020/12/07
- bug#19945: emacsclient confused by active minibuffer, Eli Zaretskii, 2020/12/07
- bug#19945: emacsclient confused by active minibuffer, Lars Ingebrigtsen, 2020/12/08