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

From: Bror Winther <[email-masked]>
Date: Tue, 22 Jul 2025 14:26:12 +0200

> On 21 Jul 2025, at 15.33, Eli Zaretskii <[email-masked]> wrote:
> 
>> From: Bror Winther <[email-masked]>
>> Date: Mon, 21 Jul 2025 15:22:06 +0200
>> Cc: [email-masked]
>> 
>> 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.

Right, then I think your suggestion of not doing a user variable is very valid.

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

How does that work when the client frame is a tty? Not the sense of emacs in the terminal but
using --eval.
I’m asking to understand why we waiting in exactly that scenario is fitting.

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

Good point. The I concur, I’ll make a new patch.

//bror