From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Change of Lisp syntax for "fancy" quotes in Emacs 27? Date: Fri, 2 Feb 2018 16:00:12 -0800 (PST) Message-ID: <150d3fe0-4ded-40cf-af3e-8e145fe8302f@default> References: <16831945-e0fb-ab64-fc31-2534adf7bcf8@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1517616017 8677 195.159.176.226 (3 Feb 2018 00:00:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Feb 2018 00:00:17 +0000 (UTC) To: Paul Eggert , Noam Postavsky , Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 03 01:00:12 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 1ehlFI-0000nr-4V for ged-emacs-devel@m.gmane.org; Sat, 03 Feb 2018 00:59:52 +0100 Original-Received: from localhost ([::1]:43187 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehlHJ-0002ej-D2 for ged-emacs-devel@m.gmane.org; Fri, 02 Feb 2018 19:01:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehlG7-0002c7-7u for emacs-devel@gnu.org; Fri, 02 Feb 2018 19:00:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ehlG4-0007ky-5J for emacs-devel@gnu.org; Fri, 02 Feb 2018 19:00:43 -0500 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:35756) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ehlG3-0007kP-Rb for emacs-devel@gnu.org; Fri, 02 Feb 2018 19:00:40 -0500 Original-Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w12Nps7n007869; Sat, 3 Feb 2018 00:00:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=esIH8YKcLCczD99DiT3rqJNNqgBXmMfsKzY1E/27Tkw=; b=MwzS66DRbJL0VlqLTK6O1WRVn0wXjXZL9ArayJQOYf7BIwC9+9alnNZRa1QtouWpvnb8 F7wu7f73h3qg2UQl6apoymtJVeJkTpdBeN0lCGIuVkfrf0m/gorKM3iu1wYpIN82ElVu F8BkstC7F12j6APwKxYv0pQIx3zYlQDV4ZZi3KM7DnYWhzzx7tIiigJy3N/b5aYrpSdq g8GHMkdk4wMHGvqUTFLejjyywKUYWWzANcjaAd1pigvQFbha8r6fPXBnqlzJSGQFYLfj V5YyD8wzGjZ8jhYEuE7e69g5VxGODhp0ygVz44nYZ/DGDdydkZ30JBCCHEf4xwfOENdb iw== Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2130.oracle.com with ESMTP id 2fvv581c32-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 03 Feb 2018 00:00:16 +0000 Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w1300EOg020296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 3 Feb 2018 00:00:14 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w1300DvR025869; Sat, 3 Feb 2018 00:00:13 GMT In-Reply-To: <16831945-e0fb-ab64-fc31-2534adf7bcf8@cs.ucla.edu> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4639.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8793 signatures=668661 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802020286 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 141.146.126.79 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:222452 Archived-At: > I see two main categories of users here, with different needs. > Less-expert users are likely to run into problems with quotes > and other characters (that's why we got bug reports), and > appreciate diagnostics pinpointing the problems; also, > programmers concerned about security are likely to want these > confusing characters to be diagnosed, to prevent an attacker > from sending code that is easily read one way but actually > operates in a different way. > > On the other hand, programs that generate Elisp code might > prefer not having to special-case these characters. So > perhaps there should be a buffer-local variable that controls > which behavior is selected. The default behavior should be > the one that caters better to general users and is safer. The distinction I think needs to be made is between: 1. Trying to _warn users_ (all users, less-expert or not) about possible misuse of particularly confusable chars. This just warns about possible pilot error. 2. _Changing Lisp_ reading and evaluating, to treat some (all?) confusable characters specially, changing their syntax and requiring them to be escaped in order to be treated normally (i.e., as they have been treated so far). I object to #2, NOT to #1. #1: By all means, we should try to help users. We can issue byte-compilation warnings and some interactive warnings - provided we can helpfully and unambiguously distinguish the right situations. #2 changes Lisp in non-neglible, non-helpful ways. See bug #30217 for more. ---- There are lots more characters to which the same non-bug "fix" of changing Lisp might be applied (which means that users will wonder why this confusable char is treated specially, and not that one). Such chars include pretty much anything that could be confused with anything that is ever used as a delimiter in Emacs Lisp: brackets (in the British sense) of all sorts: parens, square, angle, curly. There are really quite a few such bracket-confusables. Such chars also include pretty much anything that could be confused with any other chars that are used specially in Lisp: period, comma, quote, backquote, colon. Again: there are quite a few such confusables. They even include chars that could be confused with the directory separators used in Emacs Lisp. Finally (?), they include chars that could be confused with the ASCII-digit numerals 0123456789. There are lots of these confusables too. (Even with just ASCII there are confusables. Think of what some use in passwords or leet: zero vs uppercase letter O, digit 1 vs lowercase letter l, etc. We've just gotten used to carefully distinguishing such chars. Now there are many more, and slighter, differences to get used to.) ---- Beyond the question of which chars to treat specially, there's the question of where - in which contexts - to try to distinguish them. Contexts include such places as sexps being evaluated, doc strings, and comments. They can also include fonts: a given character might be confusable, or more confusable, in one font than in another. Even font size can make a difference (with some fonts I find myself zooming in to see whether a quote-thingy might really be a curly quote). The questions of which chars and where (context) are both relevant even if we only warn users (#1) and do not change Lisp syntax (#2). ---- At the very least, I would hope that if we do anything at all about this we would start by only warning. I really hope we will not change Lisp syntax for this, i.e., I hope we revert the change that has been made so far for Emacs 27. > While we're on the topic, I suggest using the Unicode > confusables list ... to come up with a list of confusing > alternatives for each character that has a special meaning > in Emacs Lisp. This should be better than our trying to > come up with our own, ad-hoc list. > > For example, U+A78C LATIN SMALL LETTER SALTILLO (=EA=9E=8C) looks > almost exactly like an apostrophe on my screen and is in > the confusables list, but is not a character that Emacs > currently checks for. Yup, and that's just one tiny tip of this terribly tippy iceberg.