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

From: Bror Winther <[email-masked]>
Date: Sun, 20 Jul 2025 22:07:10 +0200

> 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.

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.

For example, if you’re not using Evil, consider (windmove-up). Previously,
calling it with: `emacsclient --eval "(windmove-up)"` would return instantly,
even if there was no window in that direction and Emacs showed "No window up
from the selected window". This immediate return allowed my script to pass
control to the window manager. Currently, with the new 2-second delay, the
script halts for 2 seconds before passing control, only to display an error in the
minibuffer.

>> +(defcustom server-error-display-wait 2
>> +  "Number of seconds the server waits when displaying an error."
>> +  :type 'integer
>> +  :version "30.1")
> 
> 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. 

For instance:

```
emacs —daemon 
emacsclient --eval "(windmove-up)” 
```

will now take 2 seconds longer due to the display wait. 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)_

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.
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.