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

[Eli Zaretskii]

> Date: Sat, 3 Feb 2018 08:16:15 -0800 (PST)
> From: Drew Adams <address@hidden>
> Cc: address@hidden
> 
> > 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?

Those bug reports complained about obscure error messages that are
unhelpful when a Lisp programmer tries to figure out the root cause.
I'm saying that we should find an alternative way of making clear,
helpful error messages in those special cases where characters which
display similarly might make the error message confusing if it just
cites the symbol's name.

For example, suppose you have a Lisp program that produces the
following error message when compiled/executed:

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

You then type "C-h v abbrevs-changed RET" and get the expected result,
meaning that the variable is known to Emacs.  How quickly will you be
able to spot the cause of the error message?

The change that got reverted from the emacs-26 branch was about a
similar case, but for a character that's much more important for Lisp
than 'a': it's about the character used to quote symbol names.  But
the essence is the same: due to how characters are displayed, some
characters can be confused for others.

We want to find a way of identifying such situation and telling the
Lisp programmer about that in clear and easily understandable ways.
One way, perhaps too radical one, is to reject such "confusable"
characters outright.  We could decide that we don't want such a
radical solution, but that doesn't mean we should give up on the
attempt to find some other solution for the problem.  Neither does it
mean we should proclaim people who installed the change as enemies of
the society.

> Bug #23425, on the other hand, is a gigantic
> stream-of-consciousness about anything and
> everything [...]
> [...]
> 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?

I could turn the table and ask you how is it helpful to dump on us all
your random thoughts about this, instead of simply saying you didn't
understand the relevance and asking for more explanations.  Which I
just provided.

I hope now the issue is clear enough.

> 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?

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, which is the syntax of specifying a quoted symbol name using a
"strange quote".  If we are good in writing and indexing our ELisp
manual, then I'd expect to find there an index entry for "strange
quote", which will land me where this issue is explained.  Case
closed.

Once again, I can agree that this measure might be too harsh, but I
would still like to see clear diagnostics of such typos, and like
Paul, I thing we should take our inspiration from the Unicode
Standard's notion of "confusables".  Ideas and proposals for patches
along those lines are welcome.  Ignoring the problem, or trying to
convince us that it doesn't exist, is not.

> Either doing nothing or trying to warn about such
> gotchas is right.  Changing Lisp syntax here is
> not right.

Doing nothing would be ignoring the problem.  That changing Lisp
syntax is not right is your opinion: legitimate, but clearly not
shared by at least some.

> 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.