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: Sat, 3 Feb 2018 08:16:15 -0800 (PST) Message-ID: <1fedc60d-35a7-4ff0-adbb-b6b8306d192f@default> References: <83o9l6bhfs.fsf@gnu.org> 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 1517674481 17248 195.159.176.226 (3 Feb 2018 16:14:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Feb 2018 16:14:41 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii , Noam Postavsky Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 03 17:14:37 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 1ei0Sa-00047Q-Eo for ged-emacs-devel@m.gmane.org; Sat, 03 Feb 2018 17:14:36 +0100 Original-Received: from localhost ([::1]:47500 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ei0Ub-0005qC-Ap for ged-emacs-devel@m.gmane.org; Sat, 03 Feb 2018 11:16:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56981) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ei0UN-0005nq-5B for emacs-devel@gnu.org; Sat, 03 Feb 2018 11:16:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ei0UL-0001OY-SQ for emacs-devel@gnu.org; Sat, 03 Feb 2018 11:16:27 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:49244) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ei0UG-0001Mf-9e; Sat, 03 Feb 2018 11:16:20 -0500 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w13GC5Aq179659; Sat, 3 Feb 2018 16:16:17 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=VmX+H6t0AsvrfWKoCXoJtiCFXIeh5/SZN/H9IHTKSs4=; b=pDsRN6LS8+qFVAjl7ckWJ8Sv+VDyKTED2P0CLVhTIxRCeUPziMzlWLVqtKP+Kw+HXTkK kTVo2jjYXoUca7u9MbgQLwnuXAQxPBtpZ+cfAfgyGKiLX/JRr+rK2eTC0DsQAXR/JmKI XF3N2Swh4p/NLvH8Wnjt8HoXAMm5o85zBoPzTV6YpCPwZacmBD8mIzcBO36jQr8SgOAa Y/SZaJH/nTG1CvaiIN5tNz3qDlbqLeq43yWUuFDYWy7Vb/rQfJLzgbFb8gamiwfocegz R0HArtu6BeRrLBt330YsU14Xyx7VFa26qB4KmOyW9jtQZCpO2FfKuhrf/lSx++RB3GZ9 Iw== Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2fw51w90w3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 03 Feb 2018 16:16:17 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w13GGGRM017469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 3 Feb 2018 16:16:17 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w13GGGST015462; Sat, 3 Feb 2018 16:16:16 GMT In-Reply-To: <83o9l6bhfs.fsf@gnu.org> 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=8794 signatures=668662 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-1802030216 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 141.146.126.78 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:222467 Archived-At: > The bug reports which triggered the above changes are bug#2967 and > bug#23425. So any proposal to remove those changes should also > suggest an alternative for handling those bug reports. For "handling those bug reports"? Are we to add more cans of worms to this question, obscuring it? AFAICT, no alternatives to handling those bugs are needed because of reverting the Lisp syntax change made for bug #30217. Can you point to how/why reverting that change would necessitate alternative fixes for those bugs? Bug #2967 just asked for a warning, e.g. during byte-compilation or loading. There's no objection here to warning. Bug #2967 did not ask for (or get) a change in Lisp syntax. I see no negative impact on #2967 from reverting the Lisp-syntax "fix" to #30217. Even #30217 did not ask for such a syntax change. Warning is sufficient for fixing #30217 too. Bug #23425, on the other hand, is a gigantic stream-of-consciousness about anything and everything to do with Paul's changes to Emacs over the last few years wrt curly quotes. It's not a single bug report thread - it's all over the map. In any case, #23425, like #2967 (and even #30217), is not about what was done to "fix" #30217 - changing Lisp syntax for fancy quotes. How is it helpful to throw all of #23425 into this Lisp syntax-change question, as if the present issue puts into question everything ever discussed about curly quotes? Or do you have something specific in mind here wrt #23425 - some part of it? Something that would actually be impacted negatively by reverting the Lisp syntax changes for #30217? If so, please identify it. But if you mean only the ability to get confused by copy+pasting Lisp code that has a fancy quote mark somewhere in place of ordinary ASCII apostrophe ('), e.g., (setq foo =E2=80=99bar), then that's just the same pilot-error gotcha as for bug #30217. There are many gotchas in Lisp. You can see repeated postings of some at various places (e.g., help-gnu-emacs, emacs.stackexchange). E.g., the error that a given Lisp function is not defined (because its library was not loaded). The pilot error described in bug #30217 is not even a commonly reported one. The "fix" made in #30217 is an overreaction. So one solution to #30217 is to do nothing - just revert the misguided Lisp syntax change. Users will learn that gotcha the same way they learn others. Not every report of a gotcha needs to lead to changes to Emacs. If we do nothing there will continue to be some such pilot errors, of course. But we already raise an error if the code leads to a problem. And the original error message from bug #23425 is _more_ meaningful and helpful, not less, than the new one after the "fix". The original error msg of #23425: (wrong-number-of-arguments setq 31) tells you pretty much that setq is missing an argument or it has too many, which makes you look at its arguments. Not so obscure. And accurate. The new error msg: (invalid-read-syntax "strange quote" "=E2=80=99") is obscure. Invalid read syntax when reading what? What's invalid about it? Confusion - not understanding an accurate error msg, is not the same thing as Lisp itself having a bug because such a character is included in a symbol name. Another solution is to try to warn users about the use of confusables. That's actually many solutions, because it requires handling different chars and different gotcha contexts differently, and carefully. But unlike a syntax change it's not an all-or-nothing thing: we could add warnings here and there, as something might be better than nothing. Either doing nothing or trying to warn about such gotchas is right. Changing Lisp syntax here is not right. Lisp doesn't have a bug here. This is all about pilot error - the same kind of thing that happens when someone mistypes `,' for `.' for dotted-pair syntax, or types `.' in `a.b' intending dotted-pair syntax but getting a symbol instead, or quotes a sexp expecting the sexp to be evaluated. Yes, a user might scratch her head when seeing the error message from such a mistake, but the error message is right, not wrong, and eventually the light turns on. And this enlightenment is aided by the fact that Lisp syntax is so simple. The "fix" for bug #30217 goes in the opposite direction. It makes Lisp syntax more complex and makes understanding syntax mistakes more difficult.