GNU bug report logs - #24649
24.5; Why no standard error for "Trailing garbage following expression"?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24649 in the body.
You can then email your comments to 24649 AT debbugs.gnu.org in the normal way.

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

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

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.5; Why no standard error for "Trailing garbage following
 expression"?
Date: Sun, 9 Oct 2016 18:03:04 +0000 (UTC)

Shouldn't this error be a standard error?  If not a new standard error,
shouldn't it at least use one of the existing standard errors, such as
`scan-error' or `invalid-read-syntax'?

Otherwise, how to easily handle this error (e.g., to tell the user to
correct the input being read and then read again)?

In GNU Emacs 24.5.1 (i686-pc-mingw32)
 of 2015-04-11 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/usr --host=i686-pc-mingw32'

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 24649 <at> debbugs.gnu.org
Subject: Re: bug#24649: 24.5; Why no standard error for "Trailing garbage
 following expression"?
Date: Sat, 27 Jul 2019 16:11:52 +0200

Drew Adams <drew.adams <at> oracle.com> writes:

> Shouldn't this error be a standard error?  If not a new standard error,
> shouldn't it at least use one of the existing standard errors, such as
> `scan-error' or `invalid-read-syntax'?
>
> Otherwise, how to easily handle this error (e.g., to tell the user to
> correct the input being read and then read again)?

Makes sense to me.  I'm not sure what signal to use, though -- anybody
got an idea?

Tentative patch:

diff --git a/src/minibuf.c b/src/minibuf.c
index 14a0dbe762..f6cf47f1f2 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -169,7 +169,8 @@ string_to_object (Lisp_Object val, Lisp_Object defalt)
 	{
 	  int c = SREF (val, i);
 	  if (c != ' ' && c != '\t' && c != '\n')
-	    error ("Trailing garbage following expression");
+	    xsignal1 (Qinvalid_read_syntax,
+		      build_string ("Trailing garbage following expression"));
 	}
     }
 


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 24649 <at> debbugs.gnu.org
Subject: Re: bug#24649: 24.5; Why no standard error for "Trailing garbage
 following expression"?
Date: Fri, 23 Aug 2019 02:25:37 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Drew Adams <drew.adams <at> oracle.com> writes:
>
>> Shouldn't this error be a standard error?  If not a new standard error,
>> shouldn't it at least use one of the existing standard errors, such as
>> `scan-error' or `invalid-read-syntax'?
>>
>> Otherwise, how to easily handle this error (e.g., to tell the user to
>> correct the input being read and then read again)?
>
> Makes sense to me.  I'm not sure what signal to use, though -- anybody
> got an idea?

[...]

> +	    xsignal1 (Qinvalid_read_syntax,
> +		      build_string ("Trailing garbage following expression"));

There weren't any comments, so I've now applied this.  If somebody has a
better idea for the error signal, please amend.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 24649 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#24649: 24.5;
 Why no standard error for "Trailing garbage following expression"?
Date: Fri, 23 Aug 2019 11:06:50 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Fri, 23 Aug 2019 02:25:37 +0200
> Cc: 24649 <at> debbugs.gnu.org
> 
> >> Shouldn't this error be a standard error?  If not a new standard error,
> >> shouldn't it at least use one of the existing standard errors, such as
> >> `scan-error' or `invalid-read-syntax'?
> >>
> >> Otherwise, how to easily handle this error (e.g., to tell the user to
> >> correct the input being read and then read again)?
> >
> > Makes sense to me.  I'm not sure what signal to use, though -- anybody
> > got an idea?
> 
> [...]
> 
> > +	    xsignal1 (Qinvalid_read_syntax,
> > +		      build_string ("Trailing garbage following expression"));
> 
> There weren't any comments, so I've now applied this.  If somebody has a
> better idea for the error signal, please amend.

Thanks, but this change needs to be reflected in the ELisp manual,
where currently invalid-read-syntax is documented for a different use
case.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24649 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#24649: 24.5; Why no standard error for "Trailing garbage
 following expression"?
Date: Fri, 23 Aug 2019 10:16:04 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> > +	    xsignal1 (Qinvalid_read_syntax,
>> > +		      build_string ("Trailing garbage following expression"));
>> 
>> There weren't any comments, so I've now applied this.  If somebody has a
>> better idea for the error signal, please amend.
>
> Thanks, but this change needs to be reflected in the ELisp manual,
> where currently invalid-read-syntax is documented for a different use
> case.

Let's see...  Qargs_out_of_range would be inappropriate...  And
Qwrong_type_argument...  Perhaps the closest one of the predefined
errors would be Qend_of_file?

Or we could have a new one.  `garbage-follows-expression'?  That's
pretty explicit.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 24649 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#24649: 24.5; Why no standard error for "Trailing garbage
 following expression"?
Date: Fri, 23 Aug 2019 12:18:16 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: drew.adams <at> oracle.com,  24649 <at> debbugs.gnu.org
> Date: Fri, 23 Aug 2019 10:16:04 +0200
> 
> >> > +	    xsignal1 (Qinvalid_read_syntax,
> >> > +		      build_string ("Trailing garbage following expression"));
> >> 
> >> There weren't any comments, so I've now applied this.  If somebody has a
> >> better idea for the error signal, please amend.
> >
> > Thanks, but this change needs to be reflected in the ELisp manual,
> > where currently invalid-read-syntax is documented for a different use
> > case.
> 
> Let's see...  Qargs_out_of_range would be inappropriate...  And
> Qwrong_type_argument...  Perhaps the closest one of the predefined
> errors would be Qend_of_file?
> 
> Or we could have a new one.  `garbage-follows-expression'?  That's
> pretty explicit.

We don't have to invent a new symbol, we just need to document in
"Standard errors" that this error is also signaled an the situation
described in this bug report.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24649 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#24649: 24.5; Why no standard error for "Trailing garbage
 following expression"?
Date: Fri, 23 Aug 2019 20:43:07 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> We don't have to invent a new symbol, we just need to document in
> "Standard errors" that this error is also signaled an the situation
> described in this bug report.

I see.  I've now done so on the trunk.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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