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: Why "symbol's value" error about a list? Date: Mon, 5 Feb 2018 13:46:38 -0800 (PST) Message-ID: <6608d822-4e12-4f17-8a67-4a0d72de538c@default> References: <83o9l6bhfs.fsf@gnu.org> <1fedc60d-35a7-4ff0-adbb-b6b8306d192f@default> <83wozu9f6r.fsf@gnu.org> <20180205203544.GA5310@ACM> 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 1517867124 17522 195.159.176.226 (5 Feb 2018 21:45:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 5 Feb 2018 21:45:24 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org, npostavs@users.sourceforge.net To: Alan Mackenzie , Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 05 22:45:19 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 1eioZI-0002f7-Dd for ged-emacs-devel@m.gmane.org; Mon, 05 Feb 2018 22:44:52 +0100 Original-Received: from localhost ([::1]:40623 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eiobJ-00082s-Ka for ged-emacs-devel@m.gmane.org; Mon, 05 Feb 2018 16:46:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34240) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eiobA-00082J-Vd for emacs-devel@gnu.org; Mon, 05 Feb 2018 16:46:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eiob9-0003UX-RS for emacs-devel@gnu.org; Mon, 05 Feb 2018 16:46:49 -0500 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:48966) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eiob6-0003TR-0J; Mon, 05 Feb 2018 16:46:44 -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 w15Lj37P032012; Mon, 5 Feb 2018 21:46:42 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=nKsX+imlg9+6YeEYw9c2+XR8j1iWBe1koZZ7+jYvwQI=; b=Ne5aOjSzQecCADQMRYwxeHgwkH1czWURHR7C0/A0mqY59EGzKtYO3VwcmikZir+v/hiZ k7IGuAAuzww0Bm8V548MbAtU0bYQRPSz9QrP4x80hHdqRVbaQrQNfTbuyOW174tFRy2r gXGjeSnpwCu5rzDdO00Hv7zAsXJqaThkY23fFfogF627rTFvuHc16LLbIn50cQfquUBH xYBi6Z/JwGV3jQG6RZYdMvvl5eOE7QkmxBtg4w20Mmayx932TdBkGIsnrt7z1FRmqknS iVxlHCLu37LeQmDNJJs179kc/5sImyvqOJME+LwVdHvkZvEpl5UEifKPKAQvc0R0JhwX 1A== Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2130.oracle.com with ESMTP id 2fxyf5809d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 05 Feb 2018 21:46:42 +0000 Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w15Lke7f024437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 5 Feb 2018 21:46:40 GMT Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w15Lkdd4015888; Mon, 5 Feb 2018 21:46:40 GMT In-Reply-To: <20180205203544.GA5310@ACM> 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=8796 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=769 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802050267 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:222567 Archived-At: > > > For example, suppose you have a Lisp program that produces the > > > following error message when compiled/executed: > > > Symbol's value as variable is void: '=D0=B0bbrevs-changed >=20 > > Does that error message really happen? If so, how can I reproduce it? >=20 > In Emacs-25.3 -Q, do M-: (message "(setq foo 'bar)") RET > followed by getting the output from *Messages* into the kill ring with > M-w, followed by M-: C-y RET. >=20 > You might think you are executing (setq foo 'bar). You're not. > You're executing (setq foo =E2=80=99bar), where the =E2=80=99 is a Unicod= e curly quote. >=20 > The error message given out is: > Symbol's value as variable is void: =E2=80=99bar That was the old, and legitimate, error message, yes. It accurately describes what is really going on (as you describe well, below). Now the message is instead (invalid-read-syntax "strange quote" "=E2=80=99"). Is that better? That's part of what this discussion is about. I suggested that the variable name be enclosed in `...'. That would make the original message clearer, I think: Symbol's value as variable is void: `=E2=80=99bar' At least it could make it more likely that you would think about looking at that quote mark. > This is a result of the change in `message', silently to convert ' to a > curly quote, by default. Some of us were unhappy at this change and > protested against it. Count me as one of those "some of us". Echoing Lisp code should do just that - no fiddling to "prettify" apostrophe to curly quote etc. > > Suppose it were 'foobaz', all ASCII, and we got an error such as > > Symbol's value as variable is void: 'foobaz > > That still seems wrong. Here's the thing: There _is_ a Lisp error - no doubt. But for Lisp the error is not that a curly quote was read as part of a symbol name. That's not a Lisp error (at least it has not been, until now.) The error is using a symbol as a variable, when it is not defined as a variable. Which is exactly what the original error message said. That's the LISP error. Is there a _user error_ here? Yes, it's the mistake of copying and pasting what was printed in *Messages*. That user mistake is excusable. And we would want to inform the user about it, if we can't prevent it. But changing Lisp read syntax to guess what might be the most helpful thing to tell a user here is NOT the solution. Should this Lisp syntax change be reverted? That's the question being discussed here. Changing the read syntax is a general, Lisp-level change. We should instead prevent this user mistake by removing its cause. The real error here is (IMO) a design error by Emacs: The expression read and copied to *Messages* should not have been "helpfully" translated to use a curly quote instead of an apostrophe. Emacs shot Lisp in the foot on this one. It's not the fault of Lisp and its reader (syntax). It's the fault of some misguided "modernization" of Emacs gone amuck. Users should not find the input (setq foo 'bar) transformed to (setq foo =E2=80=99bar), i.e., APOSTROPHE replaced by RIGHT SINGLE QUOTATION MARK. > Again "=E2=80=99foobaz", not "foobaz" is the symbol, here. Yes, and that's a legitimate symbol name. Nothing wrong with Lisp telling us that that symbol is undefined as a variable. That's exactly what the _LISP_ problem is here. That's just not the symbol that was passed to Lisp originally. That's a non-variable symbol name copied from *Messages*. The mistake was putting that in *Messages* in the first place. Where was the mistake? Lisp claiming that you used a symbol as an undefined variable? The user copying that symbol name from *Messages* and trying to evaluate its symbol as a var? Or Emacs inserting a different symbol name in *Messages*, by substituting the text "=E2=80=99bar" for the text "'bar"? The original Lisp expression was a Lisp expression, not just text. A quote mark (apostrophe) in Lisp has special meaning, special syntax. That shouldn't be ignored by some dumb (yes) substitution of curly quotes for straight quotes. > > If the error was that foobaz was void, the error message > > should not include a quote. It should say > > Symbol's value as variable is void: foobaz >=20 > Yes. No. Only if `foobaz' were indeed the symbol that was an undefined variable. But that's NOT the case here. The undefined variable here is the symbol `=E2=80=99foobaz' (from *Messages*) - it really is. The underlying mistake took place long before Lisp evaluation of the pasted sexp.