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: Tue, 6 Feb 2018 07:45:59 -0800 (PST) Message-ID: <3181c6fa-6e0d-4352-88bd-eb9288b9b995@default> References: <83o9l6bhfs.fsf@gnu.org> <1fedc60d-35a7-4ff0-adbb-b6b8306d192f@default> <83wozu9f6r.fsf@gnu.org> <20180205203544.GA5310@ACM> <6608d822-4e12-4f17-8a67-4a0d72de538c@default> <83shae7o2u.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 1517931997 11670 195.159.176.226 (6 Feb 2018 15:46:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Feb 2018 15:46:37 +0000 (UTC) Cc: acm@muc.de, npostavs@users.sourceforge.net, rms@gnu.org, Emacs developers To: Tim Cross , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 06 16:46:32 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 1ej5RO-0000GD-Iu for ged-emacs-devel@m.gmane.org; Tue, 06 Feb 2018 16:45:50 +0100 Original-Received: from localhost ([::1]:59113 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ej5TP-0000aO-Tz for ged-emacs-devel@m.gmane.org; Tue, 06 Feb 2018 10:47:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41933) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ej5Rj-0007zd-J6 for emacs-devel@gnu.org; Tue, 06 Feb 2018 10:46:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ej5Ri-0008Rb-GQ for emacs-devel@gnu.org; Tue, 06 Feb 2018 10:46:11 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:33300) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ej5Rc-0008L9-NB; Tue, 06 Feb 2018 10:46:04 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w16Ffi88180848; Tue, 6 Feb 2018 15:46:03 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=8CiIz3Hx3P3NY6DreXLBHwVhEEAq/AkCJxlChS2KMy8=; b=IXJZYGTBC2CIw57IQZq/tpC8gG0X6burph04Pr59uZ+V8cYdWfD35AtGXqdXum8W1aKf XvlaTguFl/kpnpfmpH8h+edhUSg2bJQlBkxH4Alxf3kOaBWOs1jl1cWi0T3zub5uqwbr sp2duOXYtEuSUElCUkXkies1TOnUXtlqvmkYkfKfxDVufLihsjA7pMxdTP30tS3gAad6 N1TrS45MvTDLx1cN2e79I6DKNdo1RfZ3u45/ZxcXXASTk33lvZpK2OXP46mMc59Z34XZ 4xBy3nrdmQA4kvRRSbWxVCzUF7dQpd7fEMXY5Cs94VzgGnSYXhEvzKn9vjxIyyE4tDLK ZA== Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2fydy8rmwb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 06 Feb 2018 15:46:02 +0000 Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w16Fk1BA016460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 6 Feb 2018 15:46:01 GMT Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w16Fk1PU027163; Tue, 6 Feb 2018 15:46:01 GMT In-Reply-To: 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=702 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802060198 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.86 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:222579 Archived-At: > It seems there are two issues here - they are not completely > separate, but do seem to be distinct and probably need to be > addressed in two steps.=C2=A0 > > If the statement=C2=A0 > > > Count me as one of those "some of us".=C2=A0 Echoing Lisp code > > should do just that - no fiddling to "prettify" apostrophe to > > curly quote etc. > > is correct, then I would agree it was a bad design decision. > The *Messages* buffer should display lisp code exactly as it > is read and not try to 'prettify' it. Yes. > The second issue seems to be more about how to make the error > message more informative. Yes, but it's not just about that error message. That Lisp error is about an undefined variable. But there are plenty of other contexts where users can be confused by such a gotcha. If code or a user did in fact define a variable named =E2=80=99bar then there would be no Lisp error (prior to the recent change). Such a symbol name could nevertheless be confusing in some contexts. But it's not about how best to present that undefined-variable error message. That message was telling the truth, even if in the particular context presented it might not be immediately clear to a user what the undefined symbol name is (i.e., that the name contains a curly quote). > I suspect this is a much harder problem to resolve. I don't > know what the right solution is for that, but I do know that > I would have more chance of recognising my error if the > message displayed in the buffer displays the lisp code > exactly as it was read by the reader. Precisely. That Lisp error really is about using symbol `=E2=80=99bar' as a variable. Such code can exist in different contexts, only some of which have anything to do with a user mistaking a curly quote for an apostrophe. Just as some Lisp code can mistakenly use symbol `abc' as a variable apart from any binding of it as a variable, and so provoking the undefined-variable error, so can code mistakenly use symbol `=E2=80=99bar' as an undefined variable. Such a context would have nothing to do with the newly fabricated error (invalid-read-syntax "strange quote" "=E2=80=99"). That's just the wrong error for Lisp to raise here.