Re: Why "symbol's value" error about a list?

[Eli Zaretskii <eliz@gnu.org>]

On February 6, 2018 9:32:21 AM GMT+02:00, Tim Cross <theophilusx@gmail.com> wrote:
> It seems there are two issues here - they are not completely separate,
> but
> do seem to be distinct and probably need to be addressed in two steps.
> 
> If the statement
> 
> > Count me as one of those "some of us".  Echoing Lisp code
> > should do just that - no fiddling to "prettify" apostrophe to
> > curly quote etc.
> 
> is correct, then I would agree it was a bad design decision. The
> *Messages*
> buffer should display lisp code exactly as it is read and not try to
> 'prettify' it.
> 
> The second issue seems to be more about how to make the error message
> more
> informative. I suspect this is a much harder problem to resolve. I
> don't
> know what the right solution is for that, but I do know that I would
> have
> more chance of recognising my error if the message displayed in the
> buffer
> displays the lisp code exactly as it was read by the reader.
> 
> Tim
> 
> 
> On 6 February 2018 at 15:13, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > > Date: Mon, 5 Feb 2018 13:46:38 -0800 (PST)
> > > From: Drew Adams <drew.adams@oracle.com>
> > > Cc: Eli Zaretskii <eliz@gnu.org>, npostavs@users.sourceforge.net,
> > >         emacs-devel@gnu.org
> > >
> > > > The error message given out is:
> > > >     Symbol's value as variable is void: ’bar
> > >
> > > That was the old, and legitimate, error message, yes.  It
> > > accurately describes what is really going on (as you describe
> > > well, below).
> > >
> > > Now the message is instead (invalid-read-syntax "strange quote"
> > > "’").  Is that better?
> >
> > I think it's somewhat better, because it talks about "strange
> quote",
> > which is a hint for the user about the actual problem.
> >
> > > I suggested that the variable name be enclosed in `...'.  That
> > > would make the original message clearer, I think:
> > >
> > >   Symbol's value as variable is void: `’bar'
> >
> > That might make things even more confusing, because the text
> actually
> > displayed will be this:
> >
> >     Symbol’s value as variable is void: ‘’bar’
> >
> > which loses all hints of what is being quoted here.
> >
> > > > This is a result of the change in `message', silently to convert
> ' to a
> > > > curly quote, by default.  Some of us were unhappy at this change
> and
> > > > protested against it.
> > >
> > > Count me as one of those "some of us".  Echoing Lisp code
> > > should do just that - no fiddling to "prettify" apostrophe to
> > > curly quote etc.
> >
> > That ship has sailed two Emacs releases ago.  We are trying to fix
> the
> > fallout.
> >
> > And strange quotes is only one situation where confusingly similar
> > characters can be presented in error messages, making it hard for
> > users to spot the real problem.  We are trying to find ways of
> making
> > such "typos" more evident in error messages.
> >
> > > The error is using a symbol as a variable, when it is not
> > > defined as a variable.  Which is exactly what the original
> > > error message said.
> > >
> > > That's the LISP error.  Is there a _user error_ here?
> > > Yes, it's the mistake of copying and pasting what was
> > > printed in *Messages*.
> > >
> > > That user mistake is excusable.  And we would want to
> > > inform the user about it, if we can't prevent it.  But
> > > changing Lisp read syntax to guess what might be the
> > > most helpful thing to tell a user here is NOT the solution.
> >
> > The issue is what _would_ be a helpful message in these cases.  You
> > are just saying what should _not_ be done (repeatedly), but that
> > doesn't advance us towards the solution.
> >
> > > Should this Lisp syntax change be reverted?  That's the
> > > question being discussed here.
> >
> > No, that's only part of the question.  The other, no less important
> > part is if we revert that change, how to make the confusing error
> > message less so and more helpful in understanding the user error.
> >
> >

Lisp code is not changed in messages; only quoted plain text is.