From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#30217: Ambiguity in NEWS in emacs-26.0.91 Date: Tue, 23 Jan 2018 07:53:49 -0800 (PST) Message-ID: <1a1fbaea-f291-414d-aaef-bf41ea4a5873@default> References: <20180122221743.GB4888@ACM> <5074511f-b3b3-45aa-80b4-130be08f30ec@default> <87efmho17g.fsf@users.sourceforge.net> <4c079376-7659-4962-aa73-39a4b4ed76e0@default> <878tcpnyio.fsf@users.sourceforge.net> <132fe701-a996-4708-bf39-4ee95230b8fa@default> <871sigohv9.fsf@users.sourceforge.net> 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 1516722872 19469 195.159.176.226 (23 Jan 2018 15:54:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 23 Jan 2018 15:54:32 +0000 (UTC) Cc: Alan Mackenzie , 30217@debbugs.gnu.org To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 23 16:54:27 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1ee0tn-0003ka-UY for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Jan 2018 16:54:12 +0100 Original-Received: from localhost ([::1]:36911 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ee0vm-0001s9-Py for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Jan 2018 10:56:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39100) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ee0ve-0001rd-Nw for bug-gnu-emacs@gnu.org; Tue, 23 Jan 2018 10:56:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ee0vb-0001bi-5s for bug-gnu-emacs@gnu.org; Tue, 23 Jan 2018 10:56:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60132) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ee0vb-0001bS-1V for bug-gnu-emacs@gnu.org; Tue, 23 Jan 2018 10:56:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ee0va-0000lx-MH for bug-gnu-emacs@gnu.org; Tue, 23 Jan 2018 10:56:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Jan 2018 15:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30217 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30217-submit@debbugs.gnu.org id=B30217.15167229212876 (code B ref 30217); Tue, 23 Jan 2018 15:56:02 +0000 Original-Received: (at 30217) by debbugs.gnu.org; 23 Jan 2018 15:55:21 +0000 Original-Received: from localhost ([127.0.0.1]:39793 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ee0us-0000kI-S5 for submit@debbugs.gnu.org; Tue, 23 Jan 2018 10:55:20 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:59880) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ee0ur-0000k0-9y for 30217@debbugs.gnu.org; Tue, 23 Jan 2018 10:55:17 -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 w0NFq4dp154785; Tue, 23 Jan 2018 15:55:09 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=Sq8XNCnKNuxcWpMo+HKG4DY/7x54kGY+L9U8c9NlaOU=; b=vV8ohei3xfgWtb+6lvju35X5FTF5IRze5McYNr/zqOjj7ybvM+DWDLwpPA1oW/FITdJF GRETjSSyhTUJox3XnMeYMB1lPCBZWjLlAA8uXfUIfQa0aZQDqOVf5lM3r6autZmpT7Oz NzvVMzT1FlDHG0ykGm6kULpATfXFZBL/qbhROUKN/UNypOJr3V/ZpCQ6ekQ/65BNzEvu vvdkarFbvq6I4cYNZAob0bh0IBhjl4z4AbJTef15omskOVkybiSZQ3nHGKPnNZqFe3p/ 9rPg/CZEOvwQdVl/bAG+5PmWxk0Ld7p1eWJnnFbO+URm0IZ8T466E4HWVjPmM2mv95wz MA== Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2120.oracle.com with ESMTP id 2fp7y505eu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 23 Jan 2018 15:54:38 +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 w0NFrspS003361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 23 Jan 2018 15:53:55 GMT Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w0NFrowD018039; Tue, 23 Jan 2018 15:53:51 GMT In-Reply-To: <871sigohv9.fsf@users.sourceforge.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4627.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8782 signatures=668655 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-1801230218 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:142429 Archived-At: > The OP of Bug#2967 says > I think it would be good if emacs looked for smart > quotes in .emacs files and gave a warning or notice > if it detected them. This would help troubleshooting. > Which is exactly what's being done now. It's not necessarily appropriate to satisfy every suggestion offered in every bug report. ;-) I'm not sure such a warning is good, rather than bad. I think not. If a warning was printed for each "smart quote" occurrence in a file that would surely be bad, IMO. An Emacs-Lisp file can contain pretty much anything, including lots of natural-language text. Are we now issuing warnings even for "smart quotes" in comments and strings? That would definitely be a mistake. In any case, I don't care much about byte-compiler warnings - they are not the problem I responded to. They can be ignored when they are not particularly relevant. The fact that they can sometimes represent noise is at most an annoyance, not a real problem. > The OP of Bug#23425 says > When this output is fed back into Emacs with M-:, That represents pilot error, no doubt. For `M-:' we _might_ try to provide an error message that says you included a "smart quote" and say you might want to check that that's what you intended. I'm not suggesting we do that - I prefer not. But it's conceivable, if someone is really gung ho about solving the purported problem. I doubt that would be a good idea even for `M-:'. But it would surely not be appropriate for other contexts. And even for `M-:' it's not obvious that we would come up with a good test for the cases where it would be helpful rather than confusing. > it produces an obscure error message. >=20 > The Emacs 25 error for the expression in question is > (wrong-number-of-arguments setq 31) Which tells you pretty much that setq is missing an argument or has too many, which makes you look at its arguments. Not so obscure. And accurate. > In Emacs 26.0.91, it is > (invalid-read-syntax "strange quote" "=E2=80=99") Which is completely obscure, IMO. Invalid read syntax when reading what? What's invalid about it? In fact, it is not invalid. It has never been invalid, and it shouldn't suddenly be considered invalid now. 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. > I think this is an improvement, since it does, in fact, > indicate there is a problematic use of =E2=80=99. There is NOT any problematic use of =E2=80=99 there. The user's understanding might be problematic, but that read syntax is not problematic for Lisp. Help users if we can, but don't screw Lisp in the process. (setq =E2=80=99bar 42) (setq foo =E2=80=99bar) That's perfectly fine Lisp, even if it might not be what some might expect. But now, after your "fix", the first sexp raises an error - at read time, no less. This is just wrong, IMO. You've redefined Lisp evaluation, taking away some of the importance of symbols. And this still raises no error: (setq a=E2=80=99bar 42). > Why do you think the signalling an error in this case > is a bad idea? Because it is. Ms Lisp all her users are being treated unfairly. See above, and see my previous msg. =E2=80=99bar is a fine symbol. =E2=80=99 has NO special meaning in Lisp - it is NOT like ' or ` or ( or ) or . or , or @. Now you've given it a special meaning: when in a context where ' is special, raise an error because it is not '. That's plain wrong and confusing, and it subtracts from Lisp (while adding nonsense to it). > > If no one has a real fix for such bugs yet then please just > > leave them open until someone comes up with a good idea. > > This "fix" is not a good idea - for those bugs at least. > > > > If this fix has some other purpose, then let's please > > know what that is and talk about it. > > > > But if such problems are the only reason for this "fix" > > then please consider getting rid of such silly and useless > > escaping and just change the error message >=20 > I don't quite understand what you mean by "getting rid of... escaping" > but keeping the error message. It sounds like a you are contradicting > yourself. I didn't say keep the error msg. I said that if you really think that some warning or error msg is important here then fine. But then improve the msg. But I do NOT think that an error msg or warning is good here. A warning maybe, but not an error, which prevents evaluation. (But I doubt that warnings can be used here accurately and without sowing ever more confusion.)=20 Aside from the error/warning, such _escaping_ is another bad idea. It too subtracts from Lisp (while adding nonsense to it). IMHO, this "fix" - all of its parts - should be reverted ASAP. If you want to add some better error messaging where we already raise an error, and if we can really distinguish the cases where the better messaging should be used, fine. And if you want to add some warnings, and if we can really distinguish the cases where the warnings would be appropriate - accurately, fine. To be clear, though, I'm in favor of neither of those things. Just leave it alone. Using (mistakenly or purposefully) such characters in symbol names is just another potential gotcha. There are plenty of them. Users need to learn, e.g., that . is a symbol-constituent char in Lisp - so you can have a symbol `a.b'. And (a.b) is not the same as (a . b). Will you start requiring users to escape the . in the symbol `a.b'? To be really clear, the fix proposed should be removed. Such characters, even if perhaps sometimes confusing to some users, are legitimate symbol characters. They should just be left alone. At _most_, and only if the analysis were super-accurate and crystal clear, we could consider adding warnings here or there. We must certainly not change Lisp here - no error-raising. Starting to special-case such characters will get us in a world of trouble - mark my words. And as I said, there's no limit to the supply of such chars. > Changing the error message is always possible, of course. I'm not sure > if bringing "ascii" into it would make things clearer though. Concrete > suggestions welcome. See above. Please drop this attempted "fix" altogether. It's just misguided, IMO. At most, if you are persuaded that something needs to be done about such "bugs" (warning pilots about such possible pilot error) then please bring it up in emacs-devel. You are modifying Lisp itself in a basic way. This should be a no-no. > > And besides - where do you stop doing this kind of thing? > > > > Do we do something similar for characters that can > > be mistaken for a period, in case you use one in an > > attempt at dotted-pair syntax? > > > > Do we do something similar for chars that can be > > mistaken for a comma, inside backquoted sexps? > > > > Do we do something similar for chars that can be > > mistaken for a backquote? An at-sign? Ordinary > > parentheses? >=20 > Maybe everything in the "Unicode confusables" listing? Practically > speaking, I've never heard of problems with other characters, except > perhaps in programming "puzzles", obfuscated code contents and the like. There are lots of chars that can be confused, especially given the possibility of different fonts. I didn't even mention other variants of brackets (aka square brackets), braces (aka curly brackets), angle brackets, etc. Would you try to protect a user from the confusion of copy+pasting FULLWIDTH LEFT CURLY BRACKET FF5B=EF=BD=9B in place of LEFT CURLY BRACKET 7B { in a doc string ("... \\{...}") or in a regexp? Or of using LEFT WHITE SQUARE BRACKET 301A =E3=80=9A in place of [ in a vector? Lisp is simple - and its use can be complicated. You are complicating Lisp itself immensely here. Will you provide fancy analysis for all of the possible contexts where such char confusion could arise? This is a big mistake - a crack in the foundation, IMO, even if you think of it now only as helping a user with a copy+paste error (pilot error). > > I really hope you reconsider this. To me it looks > > like an ugly hack that can bring only harm (including > > more, not less, confusion), not good. >=20 > Do you have any specific harms/confusion in mind? See above. This is *harmful* for our nice, clean Lisp - and YAGNI.