From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: bug#23425: master branch: `message' wrongly corrupts ' to curly quote. Date: Mon, 5 Jun 2017 20:37:53 +0000 Message-ID: <20170605203753.GB30946@acm.fritz.box> References: <17c1c00d-a275-5e61-0c47-6872a64a9347@cs.ucla.edu> <20170531212452.GA3789@acm.fritz.box> <07bf5f9d-e8cd-a4d9-1843-b488bfe0b92c@cs.ucla.edu> <20170602210209.GA3570@acm.fritz.box> <11c0adfb-7fdd-8d28-1a47-869e3e7043ea@cs.ucla.edu> <20170603205331.GA2130@acm.fritz.box> <20170605162737.GA30946@acm.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1496695157 10291 195.159.176.226 (5 Jun 2017 20:39:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 5 Jun 2017 20:39:17 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: Glenn Morris , 23425@debbugs.gnu.org, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 05 22:39:11 2017 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 1dHymN-0002Ln-Ig for ged-emacs-devel@m.gmane.org; Mon, 05 Jun 2017 22:39:11 +0200 Original-Received: from localhost ([::1]:35071 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dHymS-0001nv-UK for ged-emacs-devel@m.gmane.org; Mon, 05 Jun 2017 16:39:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60306) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dHymB-0001lp-Jv for emacs-devel@gnu.org; Mon, 05 Jun 2017 16:39:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dHym8-00016P-GC for emacs-devel@gnu.org; Mon, 05 Jun 2017 16:38:59 -0400 Original-Received: from ocolin.muc.de ([193.149.48.4]:49977 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1dHym8-00014e-4q for emacs-devel@gnu.org; Mon, 05 Jun 2017 16:38:56 -0400 Original-Received: (qmail 33697 invoked by uid 3782); 5 Jun 2017 20:38:54 -0000 Original-Received: from acm.muc.de (p548C78F4.dip0.t-ipconnect.de [84.140.120.244]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 05 Jun 2017 22:38:53 +0200 Original-Received: (qmail 32712 invoked by uid 1000); 5 Jun 2017 20:37:53 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.4 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:215458 Archived-At: Hello, Paul. On Mon, Jun 05, 2017 at 11:19:06 -0700, Paul Eggert wrote: > On 06/05/2017 09:27 AM, Alan Mackenzie wrote: [ .... ] > > 2745 is a good first approximation. > This is being optimistic. It's not just the message and error functions; > there are others, ranging from general functions like user-error to > more-specialized functions like icalendar--dmsg.These cannot be found > merely by a simple text search for function names. Maybe not, but 2745 remains a good first approximation. Other functions which call message will be found in their turn, and the number of calls of things like icalendar--dmsg will be small, both individually and in total. There are around 275 calls to message which have a non-literal format argument. > A simple albeit tedious and somewhat error-prone approach would be to > examine every ` and ' in every string and character constant (in > either C or Elisp) and fix those intended for the message function or > any of its callers. This is the sort of thing that I did when > converting for Emacs 25. > > The consequences of surreptitious unwanted translation are so severe > It's not surreptitious: it's documented. And this documentation is useless for preventing the problems. Somebody using message to output Lisp will use ' just as I did - and suffer the same horrendous problems trying to make sense of non-sensical error messages saying 'foo does not exist, when it plainly does. Do you, perhaps, have another strategem for preventing this problem? As I said, the burden of dealing with this translation should fall on those who are actually and consciously using it. Unless, of course, you're in favour of hackers remaining unaware of the stealthy alterations being made to their expressed intentions. Such a burden, on those wanting the translation, is small. > And the consequences are not severe: they are a minor change to > strings intended for human consumption, where humans can easily > recover from unwanted translation, and where humans who don't want > translation can easily turn it off. When I got caught by this bug there was no "easy" way to turn off the translation. The process of turning it off involved a long period of puzzlement over the non-sensical error messages referred to above, and an even longer period of being very angry at having my work messed up by Emacs. How do you propose to prevent such puzzlement and anger in the future, if not by %` and %'? And I was somebody who had been familiar with discussions on emacs-devel over such matters. Such things might not seem severe to you. I am sure they are to many people. > As I understand it, you're proposing making hundreds or thousands of > changes like this: > (error "Can't find `%s' in %s" thing where))) > => (error "Can%'t find %`%s%' in %s" thing where))) Yes. > These changes will adversely affect code readability, and this will have > a maintenance cost in the long run No. The addition of quote translation is what has affected readability. It is currently implicit and vague, a bit like the lack of connection between written English and spoken English. I am proposing restoring it to an explicit form, where the sole special character is %, as it had been for ever before Emacs 25. I don't think you've considered the maintenance cost of this impliciticity, this vagueness, the fact that people will be using ` and ' in format strings without understanding what they mean. > -- not just to whoever makes the hundreds or thousands of changes, but > to everybody who has to read the code afterwards. Those people will be able to understand the code much more easily with explicit %` and %' rather than the stealthy behind-the-back translation which happens at the moment. > It's not at all clear that this cost is greater than the benefit of > fixing some of the minor problems that you're objecting to. It's easy to minimise and dismiss other people's problems. I don't see non-sensical error messages as anything but a major problem. One of the problems of the Emacs 25 approach is that the distinction between ` and ', and the curly quotes has become vague, fuzzy, and confused. I do not want this confusion to carry on into Emacs 26. > > _Anybody_ who's used `message' knows > Perhaps I should introduce you to my students someday. I teach them > elements of Emacs and I assure you that some of them do not know. The ones who have never used `message', you mean. You're not seriously telling me that any of your students who've written a message call with a "%s" in the format string remain unaware of the role of %, are you? > Although I readily concede that more people know about % than ` or ', > this doesn't alter the fact that it causes problems to support special > characters of any sort in the message function. Elisp code needed to use > (message "%s" STR) even before the change you're objecting to, Did it? When and why? > and it'd still need (message "%s" STR) even if the change were > reverted. When and why? > > It is not merely annoying, it is hideously irregular. Having to write > > (message "%s" (format "...." arg1 arg2 ....)) screams out "we didn't > > think this through properly". > Yes, and that's just as true for % as it is for ` and '. Not at all. In message, % causes no problems. ` and ' do. > In hindsight, the message function should have had a better API. > Hindsight is wonderful.... If you think a better API could have been conceived, outline it. I don't. And even if it could, that's no excuse to worsen the workings of message. -- Alan Mackenzie (Nuremberg, Germany).