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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 26 Jul 2023 11:07:24 -0700
> Cc: 64866@debbugs.gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 7/25/2023 7:30 PM, Eli Zaretskii wrote:
> > 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.
> 
> In this case, the user *can* see the error though: it's printed in the 
> terminal that they called `emacsclient -e '(error "oops")'` from.

emacsclient writes the error message to its stderr, but it immediately
exits.  When it exits and the Emacs frame is deleted, if it was a TTY
frame which was displayed on that sane terminal, the message is
deleted because Emacs clears the terminal when it deletes the frame.

I guess your experience is from GUI frames or something?  But even in
that case it is not guaranteed that the error message will be seen,
because emacsclient could be called with -nowait and in background.

So I consider relying on this message as not a good idea, especially
for error messages that usually tell something about the problem.
Imagine the frustration of a user who sees the message flashing, but
cannot read it.

I think the delay that sometimes gets in the way is a small price to
pay for this important feature.

> Strangely, I tried running this and I still see a 2 second delay:
> 
>    emacsclient -e '(let ((minibuffer-message-timeout 0)) (error "oops"))'
> 
> I'm not sure why that doesn't work...

Why did you think it should?  According to its documentation it only
affects minibuffer-message.  The 2-sec delay in the above case is done
by an explicit call to sit-for with a hard-coded argument of 2 sec.
See server-return-error.