GNU bug report logs -
#79058
30.1; involking signal using emacsclient takes very long time to complete ~2 seconds
Previous Next
Full log
Message #38 received at 79058 <at> debbugs.gnu.org (full text, mbox):
> On 21 Jul 2025, at 15.33, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> 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.
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
This bug report was last modified 18 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.