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

[Drew Adams]

> The bug reports which triggered the above changes are bug#2967 and
> bug#23425.  So any proposal to remove those changes should also
> suggest an alternative for handling those bug reports.

For "handling those bug reports"?  Are we to add
more cans of worms to this question, obscuring it?

AFAICT, no alternatives to handling those bugs
are needed because of reverting the Lisp syntax
change made for bug #30217.  Can you point to
how/why reverting that change would necessitate
alternative fixes for those bugs?

Bug #2967 just asked for a warning, e.g. during
byte-compilation or loading.  There's no
objection here to warning.

Bug #2967 did not ask for (or get) a change in
Lisp syntax.  I see no negative impact on #2967
from reverting the Lisp-syntax "fix" to #30217.

Even #30217 did not ask for such a syntax change.
Warning is sufficient for fixing #30217 too.

Bug #23425, on the other hand, is a gigantic
stream-of-consciousness about anything and
everything to do with Paul's changes to Emacs
over the last few years wrt curly quotes.
It's not a single bug report thread - it's
all over the map.

In any case, #23425, like #2967 (and even
#30217), is not about what was done to "fix"
#30217 - changing Lisp syntax for fancy quotes.

How is it helpful to throw all of #23425 into
this Lisp syntax-change question, as if the
present issue puts into question everything
ever discussed about curly quotes?

Or do you have something specific in mind here
wrt #23425 - some part of it?  Something that
would actually be impacted negatively by
reverting the Lisp syntax changes for #30217?
If so, please identify it.

But if you mean only the ability to get confused
by copy+pasting Lisp code that has a fancy quote
mark somewhere in place of ordinary ASCII
apostrophe ('), e.g., (setq foo ’bar), then
that's just the same pilot-error gotcha as for
bug #30217.

There are many gotchas in Lisp.  You can see
repeated postings of some at various places
(e.g., help-gnu-emacs, emacs.stackexchange).
E.g., the error that a given Lisp function is
not defined (because its library was not loaded).

The pilot error described in bug #30217 is not
even a commonly reported one.  The "fix" made
in #30217 is an overreaction.

So one solution to #30217 is to do nothing - just
revert the misguided Lisp syntax change.  Users
will learn that gotcha the same way they learn
others.  Not every report of a gotcha needs to
lead to changes to Emacs.

If we do nothing there will continue to be some
such pilot errors, of course.  But we already
raise an error if the code leads to a problem.

And the original error message from bug #23425
is _more_ meaningful and helpful, not less,
than the new one after the "fix".

The original error msg of #23425:
  (wrong-number-of-arguments setq 31)

tells you pretty much that setq is missing an
argument or it has too many, which makes you
look at its arguments.  Not so obscure.  And
accurate.

The new error msg:
  (invalid-read-syntax "strange quote" "’")

is obscure.  Invalid read syntax when reading
what?  What's invalid about it?

Confusion - not understanding an accurate error
msg, is not the same thing as Lisp itself having
a bug because such a character is included in a
symbol name.

Another solution is to try to warn users about
the use of confusables.

That's actually many solutions, because it
requires handling different chars and different
gotcha contexts differently, and carefully.
But unlike a syntax change it's not an
all-or-nothing thing: we could add warnings here
and there, as something might be better than
nothing.

Either doing nothing or trying to warn about such
gotchas is right.  Changing Lisp syntax here is
not right.  Lisp doesn't have a bug here.

This is all about pilot error - the same kind of
thing that happens when someone mistypes `,' for
`.' for dotted-pair syntax, or types `.' in `a.b'
intending dotted-pair syntax but getting a symbol
instead, or quotes a sexp expecting the sexp to
be evaluated.

Yes, a user might scratch her head when seeing
the error message from such a mistake, but the
error message is right, not wrong, and eventually
the light turns on.

And this enlightenment is aided by the fact that
Lisp syntax is so simple.  The "fix" for bug
#30217 goes in the opposite direction.  It makes
Lisp syntax more complex and makes understanding
syntax mistakes more difficult.