* bug#61658: 30.0.50; server-eval-at might handle unreadable results better
@ 2023-02-20 16:25 Sean Whitton
2023-02-20 17:09 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Sean Whitton @ 2023-02-20 16:25 UTC (permalink / raw)
To: 61658
Hello,
I use server-eval-at to call a function, in another daemon, which
returns a buffer. So, server-eval-at tries (read "#<buffer *foo*>")
which of course fails, and indeed signals an error.
I wonder if server-eval-at should return a special value to indicate
that the remote computation returned something that is not readably
printable? Or signal a particular error, which the caller might catch?
--
Sean Whitton
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#61658: 30.0.50; server-eval-at might handle unreadable results better
2023-02-20 16:25 bug#61658: 30.0.50; server-eval-at might handle unreadable results better Sean Whitton
@ 2023-02-20 17:09 ` Eli Zaretskii
2023-02-22 17:28 ` Sean Whitton
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2023-02-20 17:09 UTC (permalink / raw)
To: Sean Whitton; +Cc: 61658
> From: Sean Whitton <spwhitton@spwhitton.name>
> Date: Mon, 20 Feb 2023 09:25:34 -0700
>
> I use server-eval-at to call a function, in another daemon, which
> returns a buffer. So, server-eval-at tries (read "#<buffer *foo*>")
> which of course fails, and indeed signals an error.
>
> I wonder if server-eval-at should return a special value to indicate
> that the remote computation returned something that is not readably
> printable? Or signal a particular error, which the caller might catch?
Why can't you make that function return something more sensible? Or
even just nil?
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#61658: 30.0.50; server-eval-at might handle unreadable results better
2023-02-20 17:09 ` Eli Zaretskii
@ 2023-02-22 17:28 ` Sean Whitton
2023-02-22 20:07 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Sean Whitton @ 2023-02-22 17:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 61658
Hello,
On Mon 20 Feb 2023 at 07:09PM +02, Eli Zaretskii wrote:
>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Date: Mon, 20 Feb 2023 09:25:34 -0700
>>
>> I use server-eval-at to call a function, in another daemon, which
>> returns a buffer. So, server-eval-at tries (read "#<buffer *foo*>")
>> which of course fails, and indeed signals an error.
>>
>> I wonder if server-eval-at should return a special value to indicate
>> that the remote computation returned something that is not readably
>> printable? Or signal a particular error, which the caller might catch?
>
> Why can't you make that function return something more sensible? Or
> even just nil?
Yes, that is a way to handle cases like this. I was thinking it might
be better to have
(define-error 'server-return-invalid-read-syntax
"Remote function returned unreadable form"
'invalid-read-syntax)
for a more flexible way to handle the situation.
--
Sean Whitton
^ permalink raw reply [flat|nested] 12+ messages in thread* bug#61658: 30.0.50; server-eval-at might handle unreadable results better
2023-02-22 17:28 ` Sean Whitton
@ 2023-02-22 20:07 ` Eli Zaretskii
2023-02-23 0:24 ` Sean Whitton
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2023-02-22 20:07 UTC (permalink / raw)
To: Sean Whitton; +Cc: 61658
> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: 61658@debbugs.gnu.org
> Date: Wed, 22 Feb 2023 10:28:05 -0700
>
> >> I use server-eval-at to call a function, in another daemon, which
> >> returns a buffer. So, server-eval-at tries (read "#<buffer *foo*>")
> >> which of course fails, and indeed signals an error.
> >>
> >> I wonder if server-eval-at should return a special value to indicate
> >> that the remote computation returned something that is not readably
> >> printable? Or signal a particular error, which the caller might catch?
> >
> > Why can't you make that function return something more sensible? Or
> > even just nil?
>
> Yes, that is a way to handle cases like this. I was thinking it might
> be better to have
>
> (define-error 'server-return-invalid-read-syntax
> "Remote function returned unreadable form"
> 'invalid-read-syntax)
>
> for a more flexible way to handle the situation.
But what we have now already gives you almost the same information:
invalid-read-syntax, "#"
I'm not sure I understand what would the above add to this. Is
"Remote function returned unreadable form" really that much more
informative, when the user doesn't expect an error?
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#61658: 30.0.50; server-eval-at might handle unreadable results better
2023-02-22 20:07 ` Eli Zaretskii
@ 2023-02-23 0:24 ` Sean Whitton
2023-02-23 6:24 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Sean Whitton @ 2023-02-23 0:24 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 61658
Hello,
On Wed 22 Feb 2023 at 10:07PM +02, Eli Zaretskii wrote:
>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Cc: 61658@debbugs.gnu.org
>> Date: Wed, 22 Feb 2023 10:28:05 -0700
>> [...]
>> Yes, that is a way to handle cases like this. I was thinking it might
>> be better to have
>>
>> (define-error 'server-return-invalid-read-syntax
>> "Remote function returned unreadable form"
>> 'invalid-read-syntax)
>>
>> for a more flexible way to handle the situation.
>
> But what we have now already gives you almost the same information:
>
> invalid-read-syntax, "#"
>
> I'm not sure I understand what would the above add to this. Is
> "Remote function returned unreadable form" really that much more
> informative, when the user doesn't expect an error?
I'm thinking about the design of calling code, not errors that bubble up
all the way to the user. If I want to catch this situation in calling
code, I can catch 'invalid-read-syntax'. But for that to catch only the
errors I intend to catch, I have to assume that the only call to 'read'
in server-eval-at is the one that reads the remote daemon's output. But
that's an implementation detail of server-eval-at, that could change.
--
Sean Whitton
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#61658: 30.0.50; server-eval-at might handle unreadable results better
2023-02-23 0:24 ` Sean Whitton
@ 2023-02-23 6:24 ` Eli Zaretskii
2023-02-23 17:27 ` Sean Whitton
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2023-02-23 6:24 UTC (permalink / raw)
To: Sean Whitton; +Cc: 61658
> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: 61658@debbugs.gnu.org
> Date: Wed, 22 Feb 2023 17:24:26 -0700
>
> Hello,
>
> On Wed 22 Feb 2023 at 10:07PM +02, Eli Zaretskii wrote:
>
> >> From: Sean Whitton <spwhitton@spwhitton.name>
> >> Cc: 61658@debbugs.gnu.org
> >> Date: Wed, 22 Feb 2023 10:28:05 -0700
> >> [...]
> >> Yes, that is a way to handle cases like this. I was thinking it might
> >> be better to have
> >>
> >> (define-error 'server-return-invalid-read-syntax
> >> "Remote function returned unreadable form"
> >> 'invalid-read-syntax)
> >>
> >> for a more flexible way to handle the situation.
> >
> > But what we have now already gives you almost the same information:
> >
> > invalid-read-syntax, "#"
> >
> > I'm not sure I understand what would the above add to this. Is
> > "Remote function returned unreadable form" really that much more
> > informative, when the user doesn't expect an error?
>
> I'm thinking about the design of calling code, not errors that bubble up
> all the way to the user. If I want to catch this situation in calling
> code, I can catch 'invalid-read-syntax'. But for that to catch only the
> errors I intend to catch, I have to assume that the only call to 'read'
> in server-eval-at is the one that reads the remote daemon's output. But
> that's an implementation detail of server-eval-at, that could change.
So you want server.el to catch the error and re-throw it with a
different signal in this particular case? Or am I misunderstanding?
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#61658: 30.0.50; server-eval-at might handle unreadable results better
2023-02-23 6:24 ` Eli Zaretskii
@ 2023-02-23 17:27 ` Sean Whitton
2023-02-23 17:42 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Sean Whitton @ 2023-02-23 17:27 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 61658
Hello,
On Thu 23 Feb 2023 at 08:24AM +02, Eli Zaretskii wrote:
> So you want server.el to catch the error and re-throw it with a
> different signal in this particular case? Or am I misunderstanding?
Yes, that's what I'd like to do.
--
Sean Whitton
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#61658: 30.0.50; server-eval-at might handle unreadable results better
2023-02-23 17:27 ` Sean Whitton
@ 2023-02-23 17:42 ` Eli Zaretskii
2023-02-23 18:08 ` Sean Whitton
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2023-02-23 17:42 UTC (permalink / raw)
To: Sean Whitton; +Cc: 61658
> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: 61658@debbugs.gnu.org
> Date: Thu, 23 Feb 2023 10:27:11 -0700
>
> On Thu 23 Feb 2023 at 08:24AM +02, Eli Zaretskii wrote:
>
> > So you want server.el to catch the error and re-throw it with a
> > different signal in this particular case? Or am I misunderstanding?
>
> Yes, that's what I'd like to do.
But then just define-error isn't enough, is it?
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#61658: 30.0.50; server-eval-at might handle unreadable results better
2023-02-23 17:42 ` Eli Zaretskii
@ 2023-02-23 18:08 ` Sean Whitton
2023-03-09 0:10 ` Sean Whitton
0 siblings, 1 reply; 12+ messages in thread
From: Sean Whitton @ 2023-02-23 18:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 61658
Hello,
On Thu 23 Feb 2023 at 07:42PM +02, Eli Zaretskii wrote:
>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Cc: 61658@debbugs.gnu.org
>> Date: Thu, 23 Feb 2023 10:27:11 -0700
>>
>> On Thu 23 Feb 2023 at 08:24AM +02, Eli Zaretskii wrote:
>>
>> > So you want server.el to catch the error and re-throw it with a
>> > different signal in this particular case? Or am I misunderstanding?
>>
>> Yes, that's what I'd like to do.
>
> But then just define-error isn't enough, is it?
Right. I didn't mean to suggest it was -- my apologies.
--
Sean Whitton
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#61658: 30.0.50; server-eval-at might handle unreadable results better
2023-02-23 18:08 ` Sean Whitton
@ 2023-03-09 0:10 ` Sean Whitton
2023-03-09 9:40 ` Robert Pluim
0 siblings, 1 reply; 12+ messages in thread
From: Sean Whitton @ 2023-03-09 0:10 UTC (permalink / raw)
To: 61658-done
Hello,
Now implemented. Doesn't seem to me like a NEWS entry is warranted, but
if anyone strongly disagrees I can write one.
--
Sean Whitton
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#61658: 30.0.50; server-eval-at might handle unreadable results better
2023-03-09 0:10 ` Sean Whitton
@ 2023-03-09 9:40 ` Robert Pluim
2023-03-11 18:48 ` Sean Whitton
0 siblings, 1 reply; 12+ messages in thread
From: Robert Pluim @ 2023-03-09 9:40 UTC (permalink / raw)
To: 61658; +Cc: spwhitton
>>>>> On Wed, 08 Mar 2023 17:10:51 -0700, Sean Whitton <spwhitton@spwhitton.name> said:
Sean> Hello,
Sean> Now implemented. Doesn't seem to me like a NEWS entry is warranted, but
Sean> if anyone strongly disagrees I can write one.
It changes the possible behaviour of a public function, so I think it
is warranted (and I have some comments on the docstrings, but Iʼll
address those separately).
Robert
--
^ permalink raw reply [flat|nested] 12+ messages in thread* bug#61658: 30.0.50; server-eval-at might handle unreadable results better
2023-03-09 9:40 ` Robert Pluim
@ 2023-03-11 18:48 ` Sean Whitton
0 siblings, 0 replies; 12+ messages in thread
From: Sean Whitton @ 2023-03-11 18:48 UTC (permalink / raw)
To: Robert Pluim; +Cc: 61658
Hello,
On Thu 09 Mar 2023 at 10:40AM +01, Robert Pluim wrote:
>>>>>> On Wed, 08 Mar 2023 17:10:51 -0700, Sean Whitton <spwhitton@spwhitton.name> said:
>
> Sean> Hello,
> Sean> Now implemented. Doesn't seem to me like a NEWS entry is warranted, but
> Sean> if anyone strongly disagrees I can write one.
>
> It changes the possible behaviour of a public function, so I think it
> is warranted (and I have some comments on the docstrings, but Iʼll
> address those separately).
But the new condition is a subtype of the old one, so it's a fully
backwards-compatible change to the behaviour. Indeed, barely a change.
Does anyone else have any intuitions about this?
--
Sean Whitton
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-03-11 18:48 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-02-20 16:25 bug#61658: 30.0.50; server-eval-at might handle unreadable results better Sean Whitton
2023-02-20 17:09 ` Eli Zaretskii
2023-02-22 17:28 ` Sean Whitton
2023-02-22 20:07 ` Eli Zaretskii
2023-02-23 0:24 ` Sean Whitton
2023-02-23 6:24 ` Eli Zaretskii
2023-02-23 17:27 ` Sean Whitton
2023-02-23 17:42 ` Eli Zaretskii
2023-02-23 18:08 ` Sean Whitton
2023-03-09 0:10 ` Sean Whitton
2023-03-09 9:40 ` Robert Pluim
2023-03-11 18:48 ` Sean Whitton
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).