From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Change of Lisp syntax for "fancy" quotes in Emacs 27? Date: Sat, 03 Feb 2018 19:05:32 +0200 Message-ID: <83wozu9f6r.fsf@gnu.org> References: <83o9l6bhfs.fsf@gnu.org> <1fedc60d-35a7-4ff0-adbb-b6b8306d192f@default> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1517677509 15511 195.159.176.226 (3 Feb 2018 17:05:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Feb 2018 17:05:09 +0000 (UTC) Cc: emacs-devel@gnu.org, npostavs@users.sourceforge.net To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 03 18:05:05 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 1ei1FJ-0003F0-4n for ged-emacs-devel@m.gmane.org; Sat, 03 Feb 2018 18:04:57 +0100 Original-Received: from localhost ([::1]:52464 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ei1HI-0004s1-IB for ged-emacs-devel@m.gmane.org; Sat, 03 Feb 2018 12:07:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38556) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ei1GB-0004o5-Gf for emacs-devel@gnu.org; Sat, 03 Feb 2018 12:05:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ei1G7-00009v-Fk for emacs-devel@gnu.org; Sat, 03 Feb 2018 12:05:51 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44041) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ei1G7-00009n-BL; Sat, 03 Feb 2018 12:05:47 -0500 Original-Received: from [176.228.60.248] (port=2112 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ei1G6-0000ho-NZ; Sat, 03 Feb 2018 12:05:47 -0500 In-reply-to: <1fedc60d-35a7-4ff0-adbb-b6b8306d192f@default> (message from Drew Adams on Sat, 3 Feb 2018 08:16:15 -0800 (PST)) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:222468 Archived-At: > Date: Sat, 3 Feb 2018 08:16:15 -0800 (PST) > From: Drew Adams > Cc: emacs-devel@gnu.org > > > 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? Those bug reports complained about obscure error messages that are unhelpful when a Lisp programmer tries to figure out the root cause. I'm saying that we should find an alternative way of making clear, helpful error messages in those special cases where characters which display similarly might make the error message confusing if it just cites the symbol's name. For example, suppose you have a Lisp program that produces the following error message when compiled/executed: Symbol's value as variable is void: 'аbbrevs-changed You then type "C-h v abbrevs-changed RET" and get the expected result, meaning that the variable is known to Emacs. How quickly will you be able to spot the cause of the error message? The change that got reverted from the emacs-26 branch was about a similar case, but for a character that's much more important for Lisp than 'a': it's about the character used to quote symbol names. But the essence is the same: due to how characters are displayed, some characters can be confused for others. We want to find a way of identifying such situation and telling the Lisp programmer about that in clear and easily understandable ways. One way, perhaps too radical one, is to reject such "confusable" characters outright. We could decide that we don't want such a radical solution, but that doesn't mean we should give up on the attempt to find some other solution for the problem. Neither does it mean we should proclaim people who installed the change as enemies of the society. > Bug #23425, on the other hand, is a gigantic > stream-of-consciousness about anything and > everything [...] > [...] > 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? I could turn the table and ask you how is it helpful to dump on us all your random thoughts about this, instead of simply saying you didn't understand the relevance and asking for more explanations. Which I just provided. I hope now the issue is clear enough. > 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" "’") > > is obscure. Invalid read syntax when reading > what? What's invalid about it? I think you are so eager to make your point that you are willing to claim that black is white and vice versa. Any objective person would agree that the new error message is more directly pointing to the root cause, which is the syntax of specifying a quoted symbol name using a "strange quote". If we are good in writing and indexing our ELisp manual, then I'd expect to find there an index entry for "strange quote", which will land me where this issue is explained. Case closed. Once again, I can agree that this measure might be too harsh, but I would still like to see clear diagnostics of such typos, and like Paul, I thing we should take our inspiration from the Unicode Standard's notion of "confusables". Ideas and proposals for patches along those lines are welcome. Ignoring the problem, or trying to convince us that it doesn't exist, is not. > Either doing nothing or trying to warn about such > gotchas is right. Changing Lisp syntax here is > not right. Doing nothing would be ignoring the problem. That changing Lisp syntax is not right is your opinion: legitimate, but clearly not shared by at least some. > Lisp doesn't have a bug here. That's a strawman, and you know it. We are talking about diagnostics for bugs in Lisp programs.