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:39:43 -0800 (PST) Message-ID: <450316d1-3a7f-4e37-8c94-868cc6739db8@default> References: <16831945-e0fb-ab64-fc31-2534adf7bcf8@cs.ucla.edu> <150d3fe0-4ded-40cf-af3e-8e145fe8302f@default> <7c61edae-4141-38d6-d138-5661aca7d22f@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 1517618301 4870 195.159.176.226 (3 Feb 2018 00:38:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Feb 2018 00:38:21 +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:38:16 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 1ehlqG-00007Q-5s for ged-emacs-devel@m.gmane.org; Sat, 03 Feb 2018 01:38:04 +0100 Original-Received: from localhost ([::1]:45682 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehlsF-00060Q-Nv for ged-emacs-devel@m.gmane.org; Fri, 02 Feb 2018 19:40:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47476) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehls3-0005yY-PP for emacs-devel@gnu.org; Fri, 02 Feb 2018 19:39:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ehlrz-0000xD-Ri for emacs-devel@gnu.org; Fri, 02 Feb 2018 19:39:55 -0500 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:56908) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ehlrz-0000wm-Kd for emacs-devel@gnu.org; Fri, 02 Feb 2018 19:39:51 -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 w130bNue033695; Sat, 3 Feb 2018 00:39:47 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=Rd30Wv6gV9J4kJXHRwTzWBWz0ZHMxj+DHN4ET7OeRUs=; b=QIsQ+CvHI1+nPO1Oypr4OkK8d3/ZzcDgzTefs0XvXm9DDLdUcMcotu7aDcIaIcEaE6zw D7Opbvmsb+qFvhTyaZjz6DBmCZaWy+z+UabZ00e1nI/bROchB590KJE7A+jXX8TNz1OD WOjsZJxezCNLff4XfJWY1sbe4sIW6g1e35c0PMhKGsjm8V4lGUHxPyfyMMVt6renfPip 0cSzTdhLU8ELQqdifCWIk85+CzgX73BaNCcBWeQ7N1R5ROCs5v0z/lglSM4N+2d8U20c Kf/iu1y2VA2I9ZmSwVGGJBV3OVIt6HcEaa3qU0ix0xn1Bgpc2pm+GhuENhe0MJmQIDoH gw== Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2fw2km00hp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 03 Feb 2018 00:39:47 +0000 Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w130dknh029393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 3 Feb 2018 00:39:47 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w130djDC011818; Sat, 3 Feb 2018 00:39:45 GMT In-Reply-To: <7c61edae-4141-38d6-d138-5661aca7d22f@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-1802030005 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:222456 Archived-At: > > 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. >=20 > I don't see a clear distinction between #1 and #2. That's too bad. They are really quite different. In the first case, you get a warning. In the second case your code breaks. > For example, in an adversarial environment... I don't think that's the reason for this change at all. It was not mentioned in the bug thread, AFAIK. The motivation was to prevent confusion on the part of users, not to prevent or avoid malevolent behavior. Please see the bug thread (#30217). The idea was to improve convenience and reduce confusion by someone who copy+pastes code from a web page (for example), when (for example) that page renders a normal quote as a curly quote. You want to introduce a security aspect here. I can't speak much to that. I'll simply ask whether other Lisps (e.g. Common Lisp) worry about such a risk? What does Clojure do about confusables in Lisp symbols? Does any other Lisp change the Lisp syntax and behavior to require special escaping of such chars in symbols (or elsewhere)? Sure, even if no other Lisp worries about this or takes the same approach as that proposed, that's not a proof that Emacs Lisp shouldn't. Still... Given enough motivation, you can already, today, create Lisp code (confusing, confusable, or otherwise) that is evil, even without using any consusable Unicode chars. When I was a kid we would play tricks on each other, changing a character somewhere in a friend's large deck of punched Hollerith cards - e.g., insert or remove a decimal point. You had to wait a full day to get back the result of your program run, and the result would only be a pretty cryptic error msg. Argggh! It was just good-natured fun - a game among friends. And that was only with assembler and Fortran, and we were just newbie kids. Imagine what you can do today, without bothering to rely on close Unicode confusables. Sorry, but your "security" argument just doesn't pass muster, for me.