Re: Change of Lisp syntax for "fancy" quotes in Emacs 27?

[Michael Heerdegen]

Hello,

Helpfulness of error messages surely depends on the beholder, and on
expectations.  In my eyes,

> Symbol's value as variable is void: 'аbbrevs-changed

is quite clear: you think this        ^^^^^^^^^^^^^^^^ is a quoted
thing, but the error message calls it a symbol.  So there must be a
problem with that quote, it has obviously gotten read as part of the
symbol.  Sure, you have still to find out why.  OTOH

> >   (invalid-read-syntax "strange quote" "’")

also doesn't say what's wrong with that quote.  It even calls something
a quote where there is none.  The error message is confusing.  Repeating
the pseudo quote character in the error message doesn't make it look
less like a quote.

> I think you are so eager to make your point that you are willing to
> claim that black is white and vice versa.  Any objective person would
> agree that the new error message is more directly pointing to the root
> cause

Are you really sure that every Emacs user would expect that we modify
the Lisp reader to catch typos?

FWIW, we already modified the Lisp reader to catch another style issue
(to get rid of old-style backquotes) and made it error.  It broke my
stuff (el-search) horribly - though I don't use old-style backquotes,
and for code that also doesn't use them.  Now I need to work around
`read' and define my own `read' function.  I also need to remember for a
long time that using `read' is forbidden in my library.  I even
implemented a minor mode to warn me just about that: it warns me that I
use `read' and it's forbidden.  Otherwise, I would get strange errors
when using my stuff, from time to time, whenever I added a `read' by
accident.  All other users of my package, too.  And believe me, _these_
error messages are then less understandable than

> Symbol's value as variable is void: 'аbbrevs-changed.

Misusing something fundamental as the Lisp reader to catch such stuff
should be the very last resort.  The result can get much more confusing
in situations we now don't think about.

> > Lisp doesn't have a bug here.
> That's a strawman, and you know it.  We are talking about diagnostics
> for bugs in Lisp programs.

I think it's a eligible argument.  Drew just thinks it's the wrong fix.
He may also think that no fix would maybe suffice.  That's ok, and I
think he made some good points.

We should discuss about alternative approaches to move forward.  People
often paste stuff into scratch or the M-: prompt that they copied from
elsewhere.  Maybe we could make M-: and C-x C-e check for this problem.
These could also check for other, similar frequent problems.  Any better
suggestions?


Michael.