Subject: bug#61658: 30.0.50; server-eval-at might handle unreadable results better

From: Eli Zaretskii <[email-masked]>
Date: Wed, 22 Feb 2023 22:07:09 +0200

> From: Sean Whitton <[email-masked]>
> Cc: [email-masked]
> 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?