From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Change of Lisp syntax for "fancy" quotes in Emacs 27? Date: Sat, 6 Oct 2018 08:51:18 -0700 Organization: UCLA Computer Science Department Message-ID: <5ebde087-561e-c71a-0840-d99626c02dcf@cs.ucla.edu> References: <83y3bc2378.fsf@gnu.org> <83k1mv1j1b.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1538841005 31378 195.159.176.226 (6 Oct 2018 15:50:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 Oct 2018 15:50:05 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 Cc: Noam Postavsky , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 06 17:50:00 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g8oq7-00081q-Qt for ged-emacs-devel@m.gmane.org; Sat, 06 Oct 2018 17:49:59 +0200 Original-Received: from localhost ([::1]:39584 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g8osE-0001AA-9b for ged-emacs-devel@m.gmane.org; Sat, 06 Oct 2018 11:52:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57938) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g8orc-00019r-WF for emacs-devel@gnu.org; Sat, 06 Oct 2018 11:51:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g8orb-0000o5-Rl for emacs-devel@gnu.org; Sat, 06 Oct 2018 11:51:32 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:47686) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g8orW-0000eF-9y; Sat, 06 Oct 2018 11:51:28 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 34D3F1616BD; Sat, 6 Oct 2018 08:51:22 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id yz56__lJq6XI; Sat, 6 Oct 2018 08:51:20 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 669891616BF; Sat, 6 Oct 2018 08:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bmJKvyFl5Y8a; Sat, 6 Oct 2018 08:51:19 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 7C3821616BD; Sat, 6 Oct 2018 08:51:19 -0700 (PDT) In-Reply-To: <83k1mv1j1b.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:230259 Archived-At: 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 r= eader=20 is put immediately and obviously on notice that there's something odd abo= ut that=20 code. We already require a backslash for that ordinary space (U+0020); wh= y not=20 also require it for EN SPACE (U+2002)? That will significantly lower conf= usion here. The point is not to distinguish 'foo\ bar' (with ordinary space) from 'fo= o\=E2=80=82bar'=20 (with en space); the point is to distinguish both from the 'foo bar' (two= =20 identifiers) that a reader would ordinarily expect here, because that's t= he main=20 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 a= m=20 *extremely annoyed* (to put it mildly) that malicious users can put one o= ver on=20 us by using characters that look like spaces, or parentheses, or whatever= ,=20 characters that are not what they look like. This has nothing to do with=20 confusing inexperienced users. I *really want* Elisp to be relatively imm= une to=20 this problem, at least for programs that I help maintain. And I don't wan= t the=20 immunity to work only when I'm using Emacs on a nice display: I often rea= d code=20 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=20 is routinely verified to be free of confusable characters in identifiers,= to=20 help prevent malicious code from sneaking into Emacs itself. Even if we g= ive=20 users the ability to let others shoot them, we should at least improve ou= r own=20 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=20 confusable with ASCII be escaped. Initially we can merely warn about any=20 unescaped confusables; as long as the warning is prominent enough that sh= ould be=20 OK for starters. This proposal does not prohibit their use in symbols, as= one=20 can simply escape the characters. There are other ways to skin this cat as well. We should be heading in th= is=20 direction, not removing the (admittedly inadequate) protection we already= have.