GNU bug report logs - #60592
30.0.50; emacsclient: exit with a different code when the request times out

Previous Next

To reply to this bug, email your comments to 60592 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; emacsclient: exit with a different code when the request
 times out
Date: Thu, 05 Jan 2023 22:47:49 -0700

Hello,

When calling 'emacsclient --timeout N --eval' from scripts, it would be
nice if you could determine for sure when a failure was just due to a
timeout, rather than, say, a Lisp exception.

inotifywait(1) exits with code 2 to indicate a timeout.
emacsclient could do the same.

We might then consider adding a separate exit code for a Lisp error.
Then a failure of emacsclient to connect, a request that timed out, and
an error from Lisp would be readily distinguishable.

At present the best one could do is parse emacsclient's output, but
that doesn't seem robust.

-- 
Sean Whitton

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 60592 <at> debbugs.gnu.org
Subject: Re: bug#60592: 30.0.50;
 emacsclient: exit with a different code when the request times out
Date: Fri, 06 Jan 2023 09:37:11 +0200

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Thu, 05 Jan 2023 22:47:49 -0700
> 
> When calling 'emacsclient --timeout N --eval' from scripts, it would be
> nice if you could determine for sure when a failure was just due to a
> timeout, rather than, say, a Lisp exception.
> 
> inotifywait(1) exits with code 2 to indicate a timeout.
> emacsclient could do the same.

It would be more portable to have the exception handler send a special
message to emacsclient, so that it would know the reason without
guessing.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60592 <at> debbugs.gnu.org
Subject: Re: bug#60592: 30.0.50; emacsclient: exit with a different code
 when the request times out
Date: Fri, 06 Jan 2023 10:57:18 -0700

Hello,

On Fri 06 Jan 2023 at 09:37AM +02, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Date: Thu, 05 Jan 2023 22:47:49 -0700
>>
>> When calling 'emacsclient --timeout N --eval' from scripts, it would be
>> nice if you could determine for sure when a failure was just due to a
>> timeout, rather than, say, a Lisp exception.
>>
>> inotifywait(1) exits with code 2 to indicate a timeout.
>> emacsclient could do the same.
>
> It would be more portable to have the exception handler send a special
> message to emacsclient, so that it would know the reason without
> guessing.

I think this is wholly complimentary to what I'm suggesting, right?

-- 
Sean Whitton

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 60592 <at> debbugs.gnu.org
Subject: Re: bug#60592: 30.0.50; emacsclient: exit with a different code
 when the request times out
Date: Fri, 06 Jan 2023 20:12:45 +0200

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: 60592 <at> debbugs.gnu.org
> Date: Fri, 06 Jan 2023 10:57:18 -0700
> 
> Hello,
> 
> On Fri 06 Jan 2023 at 09:37AM +02, Eli Zaretskii wrote:
> 
> >> From: Sean Whitton <spwhitton <at> spwhitton.name>
> >> Date: Thu, 05 Jan 2023 22:47:49 -0700
> >>
> >> When calling 'emacsclient --timeout N --eval' from scripts, it would be
> >> nice if you could determine for sure when a failure was just due to a
> >> timeout, rather than, say, a Lisp exception.
> >>
> >> inotifywait(1) exits with code 2 to indicate a timeout.
> >> emacsclient could do the same.
> >
> > It would be more portable to have the exception handler send a special
> > message to emacsclient, so that it would know the reason without
> > guessing.
> 
> I think this is wholly complimentary to what I'm suggesting, right?

I didn't think so, but maybe I was missing something.

My point is that if we make the exception known to emacsclient, then
when the timeout ends without exceptions, it should be clear it was a
real timeout.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60592 <at> debbugs.gnu.org
Subject: Re: bug#60592: 30.0.50; emacsclient: exit with a different code
 when the request times out
Date: Fri, 06 Jan 2023 12:03:17 -0700

Hello,

On Fri 06 Jan 2023 at 08:12PM +02, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Cc: 60592 <at> debbugs.gnu.org
>> Date: Fri, 06 Jan 2023 10:57:18 -0700
>>
>> Hello,
>>
>> On Fri 06 Jan 2023 at 09:37AM +02, Eli Zaretskii wrote:
>>
>> >> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> >> Date: Thu, 05 Jan 2023 22:47:49 -0700
>> >>
>> >> When calling 'emacsclient --timeout N --eval' from scripts, it would be
>> >> nice if you could determine for sure when a failure was just due to a
>> >> timeout, rather than, say, a Lisp exception.
>> >>
>> >> inotifywait(1) exits with code 2 to indicate a timeout.
>> >> emacsclient could do the same.
>> >
>> > It would be more portable to have the exception handler send a special
>> > message to emacsclient, so that it would know the reason without
>> > guessing.
>>
>> I think this is wholly complimentary to what I'm suggesting, right?
>
> I didn't think so, but maybe I was missing something.
>
> My point is that if we make the exception known to emacsclient, then
> when the timeout ends without exceptions, it should be clear it was a
> real timeout.

Right.  This is a good addition to my proposal -- no conflicts.

-- 
Sean Whitton

Previous Next

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