Package: emacs;
Reported by: Bror Winther <bbw <at> nobad.coffee>
Date: Sun, 20 Jul 2025 10:51:03 UTC
Severity: normal
Found in version 30.1
View this message in rfc822 format
From: Eli Zaretskii <eliz <at> gnu.org> To: Bror Winther <bbw <at> nobad.coffee> Cc: 79058 <at> debbugs.gnu.org Subject: bug#79058: 30.1; involking signal using emacsclient takes very long time to complete ~2 seconds Date: Mon, 21 Jul 2025 14:06:02 +0300
> From: Bror Winther <bbw <at> nobad.coffee> > Date: Sun, 20 Jul 2025 22:07:10 +0200 > Cc: 79058 <at> debbugs.gnu.org > > > > > On 20 Jul 2025, at 20.54, Eli Zaretskii <eliz <at> gnu.org> wrote: > > > >> From: Bror Winther <bbw <at> nobad.coffee> > >> Date: Sun, 20 Jul 2025 19:20:22 +0200 > >> Cc: 79058 <at> debbugs.gnu.org > >> > >> 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.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.