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

[Paul Eggert]

Eli Zaretskii wrote:
> I agree that viewing ELisp code outside of Emacs is a valid use case.
> But I don't think a backslash before these non-ASCII quotes will
> significantly lower the confusion potential when those characters are
> used in the source.

I don't follow. If someone writes '(let ((foo\ bar)) baz)' then a human reader 
is put immediately and obviously on notice that there's something odd about that 
code. We already require a backslash for that ordinary space (U+0020); why not 
also require it for EN SPACE (U+2002)? That will significantly lower confusion here.

The point is not to distinguish 'foo\ bar' (with ordinary space) from 'foo\ bar' 
(with en space); the point is to distinguish both from the 'foo bar' (two 
identifiers) that a reader would ordinarily expect here, because that's the main 
way a malicious hacker could confuse even experienced reviewers.
> Basically, there's a contradiction here between our desire not to
> confuse relatively inexperienced users of ELisp and help them avoid
> problems which might be hard to figure out, and our desire not to
> annoy experienced users.

That's not the point I was making. I'm an experienced Elisp user, and I am 
*extremely annoyed* (to put it mildly) that malicious users can put one over on 
us by using characters that look like spaces, or parentheses, or whatever, 
characters that are not what they look like. This has nothing to do with 
confusing inexperienced users. I *really want* Elisp to be relatively immune to 
this problem, at least for programs that I help maintain. And I don't want the 
immunity to work only when I'm using Emacs on a nice display: I often read code 
with Emacs highlighting unavailable or turned off, or without using Emacs at all.

At the very least there should be an option whereby the Emacs source code itself 
is routinely verified to be free of confusable characters in identifiers, to 
help prevent malicious code from sneaking into Emacs itself. Even if we give 
users the ability to let others shoot them, we should at least improve our own 
defenses.

> I don't see how
> we can be harsh to uses of these characters without actually
> prohibiting their use in symbols.

I already gave one proposal for doing just that: require that characters 
confusable with ASCII be escaped. Initially we can merely warn about any 
unescaped confusables; as long as the warning is prominent enough that should be 
OK for starters. This proposal does not prohibit their use in symbols, as one 
can simply escape the characters.

There are other ways to skin this cat as well. We should be heading in this 
direction, not removing the (admittedly inadequate) protection we already have.