GNU bug report logs - #79058
30.1; involking signal using emacsclient takes very long time to complete ~2 seconds

Previous Next

Full log

Message #35 received at 79058 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bror Winther <bbw <at> nobad.coffee>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1; involking signal using emacsclient takes very
 long time to complete ~2 seconds
Date: Mon, 21 Jul 2025 16:33:24 +0300

> From: Bror Winther <bbw <at> nobad.coffee>
> Date: Mon, 21 Jul 2025 15:22:06 +0200
> Cc: 79058 <at> debbugs.gnu.org
> 
>  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.
> 
> As I understand, this would mean that I would have to bind it every time I call --eval if I don’t
> want to wait for errors? I don’t think this is ideal either.

No, you don't have to bind it.  You could also use setq to set its
value globally, just like with user option.

>  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.
> 
>  ;; Display the error as a message and give the user time to see
>  ;; it, in case the error written by emacsclient to stderr is not
>  ;; visible for some reason.
> 
> My understanding was that the error might not have been written by emacsclient to stderr and thus 
> we just wait and hope the user sees it. From your comment I guess we wait for the client to show
> it which makes a bit more sense.

No, we wait for the _server_ to show it in the client frame.

> This raises another question, how does that make sense with 
> --eval then? Are we waiting, in the terminal, for the user to see the output? In that case I think it is
> perfectly reasonable to exit early as stderr usually gets written as well. I’m not sure I fully
> understand what the issue based on this doc string.

emacsclient will not exit until the server shuts down the connection.
Therefore, if the server waits, emacscilent also waits.

>  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.
> 
> That is completely fair. However it sounds like you are suggesting to include this
> as an undocumented user option instead (I could be wrong). A simple variable would definitely
> suffice but I don’t agree completely with the argument against making it a user option. Only 
> that it would be less work, which is of course true.

A variable has a doc string, so it is not undocumented.  It just isn't
a user option.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.