Subject: bug#79058: 30.1; involking signal using emacsclient takes very long time to complete ~2 seconds

From: Eli Zaretskii <[email-masked]>
Date: Mon, 21 Jul 2025 14:06:02 +0300

> From: Bror Winther <[email-masked]>
> Date: Sun, 20 Jul 2025 22:07:10 +0200
> Cc: [email-masked]
> 
> 
> 
> > On 20 Jul 2025, at 20.54, Eli Zaretskii <[email-masked]> wrote:
> > 
> >> From: Bror Winther <[email-masked]>
> >> Date: Sun, 20 Jul 2025 19:20:22 +0200
> >> Cc: [email-masked]
> >> 
> >> Sure, no problem at all. I use a tiling window manager. For this I have a script
> >> for navigating between OS windows and for consistency I use the same script to
> >> navigate windows in Emacs. The script uses emacsclient --eval “(evil-window-up
> >> 1)” to navigate a window up, if this fails it will call the window manager
> >> instead because it means that there is no window in that direction. Because the
> >> wait is now 2 seconds it takes 2 seconds to shift focus out of emacs. This might
> >> be a minor nuisance but enough to be annoying.
> > 
> > Sorry, I don't understand: the wait is only when an error message is
> > to be displayed.  Your description above doesn't involve any messages,
> > AFAIU, so how is the recipe you've shown related to your real problem?
> 
> The script waits for emacsclient to finish execution, and execution is halted
> for 2 seconds to wait for the error message to be displayed. This means that any
> script calling an Emacs command with emacsclient that results in an error now
> takes 2 seconds longer to complete than it did previously.

If there's no one to see the error message, why is the error message
issued? it should be suppressed if it is not intended for human
consumption.

> In my case, the script I use for OS window management calls Emacs to change
> windows. If there is no window in the requested direction Emacs throws an error.
> The script then tells the OS window manager to change focus instead. This now
> takes 2 seconds extra.

So my suggestion for this case is to use ignore-errors around the form
which could signal an error, or some other method of suppressing the
error.

> > Thanks, but I don't see any need to make this a user option.  If some
> > rare Lisp program needs to control the wait time after showing an
> > error message, it can let-bind a simple variable.  Users have no
> > reason to customize this time globally.
> 
> From a user perspective, calling emacsclient --eval from a shell or script, I
> would not expect it to halt execution for 2 seconds just to display an error on
> the server. Especially since this also affects workflows where Emacs is run
> daemonized. 

We had exactly opposite requests, and thus introduced this feature.
So at least some users do care about error messages in client frames.
You seem to be assuming that --eval used from a script necessarily
means that errors important for the users should never happen, but
that is definitely not the case in general.  When errors do happen, it
is important to let the user see them.

> For instance:
> 
> ```
> emacs —daemon 
> emacsclient --eval "(windmove-up)” 
> ```
> 
> will now take 2 seconds longer due to the display wait.

As I said above, using

  emacsclient --eval "(ignore-errors (windmove-up))”

should solve this problem very easily.

> Having it as a user
> option would empower users to decide whether their scripts should incur this
> delay or not, preserving the responsiveness of Emacs in integrated window
> management or automation setups.  _(please note I know that these two commands
> are a bit nonsensical given that there are no windows)_

A user option has global effect, i.e. it affects all the client
connections and frames.  By contrast, ignoring errors only where the
user's scripts really don't care about the errors will allow users to
see messages that matter.

That is why I think the proper solution is to have a simple variable
that Lisp programs could bind as part of such scripts to easily
disable the wait, if using ignore-errors or similar technique is for
some reason inconvenient or inappropriate.

> Maybe I'm misunderstanding the intetion. From the doc string I understand that
> the delay is a means to fix a bug where the error might not be written to stderr
> and thus showing the message somewhere. In daemonized mode that message is not
> being displayed anywhere yet the client waits for it to finish displaying.

The intent is to stderr of emacsclient.  The server has no way of
knowing whether the emacsclient's stderr is shown anywhere.

> While I understand the reasoning behind the fixed delay, I believe it would be
> more user-friendly to make it configurable, since the current approach halts
> execution and may not suit all use cases.

I agreed to allow this to be controllable by Lisp programs.  However,
a user option is not the only method of providing such control, and in
this case I believe it is sub-optimal, for the reason I mentioned: its
effect is global.  In addition, adding another user option requires us
to document it in user-level terms, and increases the number of user
options in Emacs that is already huge.  So I prefer to have a simple
variable rather than a user option, because the problem, when it
happens, is local and ephemeral.