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

Previous Next

Full log

View this message in rfc822 format

From: Bror Winther <bbw <at> nobad.coffee>
To: Eli Zaretskii <eliz <at> gnu.org>
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, 28 Jul 2025 05:07:16 +0200

> On 24 Jul 2025, at 09.07, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Bror Winther <bbw <at> nobad.coffee>
>> Date: Thu, 24 Jul 2025 02:29:26 +0200
>> Cc: 79058 <at> debbugs.gnu.org
>> 
>> 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.
> 
> If we can reliably detect the case where the frame showing the message
> will not be deleted when emacsclient disconnects, we could avoid
> waiting in those cases.  But I very much doubt this is possible, let
> alone simple: --eval argument and the functions it calls could, for
> example, delete a frame by their own volition, or the frame could be
> deleted because what emacsclient does triggers some Emacs mechanism
> which deletes frames in certain cases, etc.

That is a good point, possibly too many scenarios to effectively capture them 
all. No reason to make the experience inconsistent.
> 
> Since adding a variable provides a simple way of controlling this when
> needed, in addition to ignoring non-essential errors we already have,
> I doubt trying to do that automatically in some cases is worth your
> time.

I do feel that cli the option --no-wait should honor the meaning and not wait 
for errors. It smells like a bug or oversight that it doesn’t. The current behaviour 
contradicts the help text.

//bror

Previous Next

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