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

[Eli Zaretskii <eliz@gnu.org>]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 4 Oct 2018 18:01:26 -0700
> Cc: Drew Adams <drew.adams@oracle.com>
> 
> I'm afraid this patch is heading in the wrong direction, as we should be 
> more vigilant about confusables, not less.
> 
> Consider this example, abstracted from the auth-source-secrets-create 
> source code:
> 
>      (if (eq r 'secret)
>          (let ((data data))
>            (lambda () data))
>        data)

Is this example relevant to the proposed changes?  The latter only
change what we do for quote-like symbols that are not interpreted as
quotes by the Lisp reader.  You, OTOH, are raising a different
problem, one for which AFAIK we currently have no solution.

The general issue of "confusable" characters, both in Lisp code and in
user interaction, is an issue that still awaits a proper solution in
Emacs.  (Many moons ago, I was seduced to write a couple of primitives
to allow detection of confusable text that played tricks with bidi
reordering, but AFAICT those primitives are still not used, which is a
pity, IMO.)  I'd encourage people to work on this.

However, the much more narrow issue brought up by this bug report is
specifically about quote characters.  It is related to changes in our
messages, which now by default produce non-ASCII quotes, something
that made this particular problem more probable than it was before.  I
think as long as we don't disallow such characters in Lisp symbols,
the proposed treatment, via evaluation-time warning, is a reasonable
solution, slightly better than the somewhat confusing error message we
present now.

We could also augment that by displaying the confusable characters in
a distinct face, something we already do for some of them.

IOW, I disagree with "discourage" part of your opinion: there's
nothing wrong with using such characters as long as we don't formally
cease to support them.  And the commonly accepted mechanism of
pointing out potentially wrong constructs is by visual cues and
warning messages, not by erroring out.  Compare how we treat something
like this in C programs:

  if (a = b) { do something; }