[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: Change of Lisp syntax for "fancy" quotes in Emacs 27?
Date: Sat, 6 Oct 2018 08:51:18 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]