bug#64866: 30.0.50; Emacsclient block for 2 seconds when error is raised from command

[Yikai Zhao]

Thanks for your reply.

That's OK, I understand your point. Previously I thought this should
be treated as a bug because in my mind, "emacsclient -e xxxx" is
similar to "emacs --eval=xxx" (and further, similar to "python -c
xxxx"), which is a general interface to evaluate code (but maybe in a
specific environment (the server)). In that case, arbitrarily sleeping
some extra seconds in some valid evaluation scenarios seems
unexpected. Now I can see why that's not the case as the primary
function of emacsclient is to "tell a running Emacs to visit a file".


For any others who may be interested, my use case can be workaround by
using a slightly more complex command:

    RES="$(emacsclient -e "(condition-case nil (progn (windmove-right)
t) (error nil))")"
    if [ "$RES" != "t" ]; then
        return 1
    fi


On Wed, Jul 26, 2023 at 10:29 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Yikai Zhao <yikai@z1k.dev>
> > Date: Wed, 26 Jul 2023 10:10:08 +0800
> >
> >
> > After updating to recent master version of emacs, emacsclient would
> > block for an extra 2 seconds when some error is raised from command.
>
> That's deliberate: we want to allow the user to see the error message.
> It is not a bug.
>
> > Why it affects me:
> >
> > I bind some keyboard shortcut globally to a script to move either from
> > emacs window or i3wm window. It does something like this:
> >
> >    emacsclient -e '(windmove-right)' || i3-msg focus right
> >
> > It rely on the behavior that, if I'm currently in the rightmost emacs
> > buffer, '(windmove-right)' would return an error and fallback to use
> > i3-msg to move to another frame. With this bug I mentioned, it would
> > introduce 2-second delay on this action.
>
> I don't think your quite special use case is a reason good enough to
> prevent users from seeing error messages.  An error message that
> cannot be read is useless.
>
> Sorry.