unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* 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).