GNU bug report logs -
#79058
30.1; involking signal using emacsclient takes very long time to complete ~2 seconds
Previous Next
Full log
Message #56 received at 79058 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On 23 Jul 2025, at 13.10, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> From: Bror Winther <bbw <at> nobad.coffee>
>> Date: Tue, 22 Jul 2025 20:01:36 +0200
>> Cc: 79058 <at> debbugs.gnu.org
>>
>>>> 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.
>>>
>>> Sorry, I don't understand the question. Even if the client frame is a
>>> tty, it is the Emacs server that displays there, not emacsclient.
>>> emacsclient doesn't display anything on that frame, it just sends the
>>> command to the server.
>>
>> Let me see if I understand correctly and thank you for your patience with me.
>> I was under the impression that using --eval would not create a client frame
>> so your statement confuses me a bit.
>
> No, --eval doesn't disable creation of a client frame. Try this:
>
> $ emacsclient -t --eval '(message "foo")'
>
> This creates a client frame on the current terminal, and shows the
> message "foo" there.
Right, sorry for the confusion with a -t og -c option that makes sense but with
just --eval alone I don’t think the server should wait. Would you be open to a
solution that ignores the wait if the caller client does not have a child frame.
I have not researched if it is possible but would like to know if it is even worth
spending time on it.
>
>> I can’t wrap my head around the necessity of the wait in the case of --eval.
>> When you call --eval and encounter an error there is no output in the terminal
>> during the wait time. So let me rephrase my question, what are we waiting for?
>
> The expression inside --eval could signal an error. That error is
> shown on the client frame. If we delete the client frame immediately,
> the error message will only be shown on the stderr stream of
> emacsclient, and if that is not visible, the user won't have any
> opportunity of seeing the message. So we wait for the user to see the
> message on the client frame before we delete it.
Thank you for the clarification.
> On 23 Jul 2025, at 13.17, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> From: Bror Winther <bbw <at> nobad.coffee <mailto:bbw <at> nobad.coffee>>
>> Date: Tue, 22 Jul 2025 20:06:15 +0200
>> Cc: 79058 <at> debbugs.gnu.org <mailto:79058 <at> debbugs.gnu.org>
>>
>> Sorry I can see I used some confusing terms here. I wrote client frame in tty. I have since
>> found that there is no client frame and thus I understand why you didn’t understand the
>> question. I’m sorely concerned with using the --eval option only, not in in combination with
>> -c or any other option that would create a client frame. Apologies for the confusion.
>
> OK, but then your situation is very special, whereas the wait targets
> much more general use cases: it makes sure we give the user ample
> opportunity to see any error messages before they disappear from the
> screen.
I don’t think this case is rare. To execute emacsclient with only --eval is not a case where
the user should be given time because the consequences is that the user is now waiting
to see the error which I believe defeats the purpose of this fix. Options like --no-wait or
--suppress-output also have not impact on the wait time. Is that a bug or intentional.
//bror
[Message part 2 (text/html, inline)]
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.