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 18:05:42 -0800 (PST) Message-ID: <728bbe83-b43b-4a86-8b69-6afe3e414857@default> References: <87shaigcvs.fsf@gmail.com> 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 1517709906 12983 195.159.176.226 (4 Feb 2018 02:05:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 4 Feb 2018 02:05:06 +0000 (UTC) To: Aaron Ecay , Noam Postavsky , Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 04 03:05:01 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 1ei9fu-0002gq-0u for ged-emacs-devel@m.gmane.org; Sun, 04 Feb 2018 03:04:58 +0100 Original-Received: from localhost ([::1]:46992 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ei9hs-0004Ef-U3 for ged-emacs-devel@m.gmane.org; Sat, 03 Feb 2018 21:07:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58671) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ei9gt-0004EC-0q for emacs-devel@gnu.org; Sat, 03 Feb 2018 21:06:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ei9go-0001vE-8M for emacs-devel@gnu.org; Sat, 03 Feb 2018 21:05:58 -0500 Original-Received: from userp2120.oracle.com ([156.151.31.85]:41476) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ei9gn-0001v3-Vx for emacs-devel@gnu.org; Sat, 03 Feb 2018 21:05:54 -0500 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w14237dC101626; Sun, 4 Feb 2018 02:05: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=aJQGwYzK2o+YF+zXBSuswIyBYwkFNq7Ab/DPZRyxeMM=; b=XMswUldpL57+yTcZvloibTW2YMxl8TpVwos6IInpysNPvQd0War9u0mTksQnfjncb6Jo LdFqxgKT+SR/Hjs/D5HPioA7vuduKcanoPCdEQBr7o2ai++7rsjYeXQn1VfSZzN+nxXW 727rrhIWYcM+558BYsYfnWEv2Mfb10EEP3teaCSw368sVwM3jENuu0b1LhefOwvuilDW W0HxESiCerIJYDXeog0pFVlBVOHyz8saB7jAt7XUA8FJy4++q3nME4v/nUZOk2uClZRv +Eu9B3l/h8UftkNBPDqj/ysgi26qBbgiTp6rd8gPBRjGfE91GaUGHG/PchNqSeS23DYy SA== Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2fw5qx9kp2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 04 Feb 2018 02:05:46 +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 w1425jAl024444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 4 Feb 2018 02:05:45 GMT Original-Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w1425hmI014239; Sun, 4 Feb 2018 02:05:45 GMT In-Reply-To: <87shaigcvs.fsf@gmail.com> 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-1802040025 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.85 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:222480 Archived-At: > I was surprised to learn that this is the case, in light of what is > said in the Elisp reference about symbol names: > > =E2=80=9CA symbol name can > contain any characters whatever. Most symbol names are written with > letters, digits, and the punctuation characters =E2=80=98-+=3D*/=E2=80=99= . Such names > require no special punctuation; the characters of the name suffice as > long as the name does not look like a number. (If it does, write a =E2=80= =98\=E2=80=99 > at the beginning of the name to force interpretation as a symbol.) The > characters =E2=80=98_~!@$%^&:<>{}?=E2=80=99 are less often used but also= require no > special punctuation. Any other characters may be included in a symbol's > name by escaping them with a backslash.=E2=80=9D (info "(elisp) Symbol T= ype") Thank you very much for that. I guess I wasn't aware of that text. I thought that there were only a very few chars that needed to be escaped in symbol names - `,', `(', etc.: only chars that have special syntactic meaning in Lisp. I suppose that invalidates my objection, though I wonder _why_ we would require escaping so many ordinary chars. And like you I wonder whether that text is accurate. I wonder whether that is the intended design (why?) or it is just an inaccurate description of the real behavior. Trying various chars from confusables.txt, it does not seem like they require escaping (at least not yet). That text appears to be wrong. I'd prefer it if escaping was _not_ required for chars other than those mentioned in that text, including chars in confusables.txt. I think it makes more sense to require escaping only for characters that have special Lisp significance, syntactically. IOW, I prefer the actual behavior to the behavior described in that text. I don't think someone using Hebrew or Arabic or Chinese or Korean letters in a symbol name should need to escape each one (or any of them). But if the design described there has already been decided on then as best for Emacs then I guess my argument is moot. In that case, the implementation is currently waaaaaay out of whack wrt the design. And if that's the design to be implemented then I agree with you that implementing it as described in that text would at least have an advantage of consistency. > Would it be worth considering making the reader enforce this fully > specification, as an alternative to your patch? That would solve > this problem with curly quotes in symbol names (which also bit me at > one point), as well as the potential problems with other confusable > characters raised by Paul. >=20 > (It might still be desirable to add a special user-friendly error > message when the illegal characters are confusable with an ASCII > single quote, as an additional user-friendliness measure.) >=20 > if this approach is not taken, the manual should at least > be changed to match the actual behavior of the reader. That's the approach I'd prefer. Let chars be used in symbol names without escaping, except for those with special Lisp syntax. But add warnings in contexts where we think someone might have inadvertently used a confusable in place of a common character.