From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs,gmane.emacs.devel Subject: bug#23425: master branch: `message' wrongly corrupts ' to curly quote. Date: Wed, 7 Jun 2017 19:13:44 +0000 Message-ID: <20170607191344.GB2430@acm.fritz.box> References: <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> <20170605203753.GB30946@acm.fritz.box> 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 1496862916 15985 195.159.176.226 (7 Jun 2017 19:15:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 7 Jun 2017 19:15:16 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: 23425@debbugs.gnu.org, emacs-devel@gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jun 07 21:15:10 2017 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 1dIgQ7-0003ld-K3 for geb-bug-gnu-emacs@m.gmane.org; Wed, 07 Jun 2017 21:15:07 +0200 Original-Received: from localhost ([::1]:45799 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dIgQC-0003Vl-Vm for geb-bug-gnu-emacs@m.gmane.org; Wed, 07 Jun 2017 15:15:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46595) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dIgQ4-0003UP-Cg for bug-gnu-emacs@gnu.org; Wed, 07 Jun 2017 15:15:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dIgQ2-0005s9-Mx for bug-gnu-emacs@gnu.org; Wed, 07 Jun 2017 15:15:04 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59105) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dIgQ2-0005ru-JH for bug-gnu-emacs@gnu.org; Wed, 07 Jun 2017 15:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dIgQ2-0006wW-7x for bug-gnu-emacs@gnu.org; Wed, 07 Jun 2017 15:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Jun 2017 19:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23425 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23425-submit@debbugs.gnu.org id=B23425.149686289326663 (code B ref 23425); Wed, 07 Jun 2017 19:15:02 +0000 Original-Received: (at 23425) by debbugs.gnu.org; 7 Jun 2017 19:14:53 +0000 Original-Received: from localhost ([127.0.0.1]:33549 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dIgPt-0006vz-3j for submit@debbugs.gnu.org; Wed, 07 Jun 2017 15:14:53 -0400 Original-Received: from ocolin.muc.de ([193.149.48.4]:49135 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1dIgPp-0006vo-Hv for 23425@debbugs.gnu.org; Wed, 07 Jun 2017 15:14:51 -0400 Original-Received: (qmail 6316 invoked by uid 3782); 7 Jun 2017 19:14:47 -0000 Original-Received: from acm.muc.de (p548C713C.dip0.t-ipconnect.de [84.140.113.60]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 07 Jun 2017 21:14:46 +0200 Original-Received: (qmail 4977 invoked by uid 1000); 7 Jun 2017 19:13:44 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de 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:133380 gmane.emacs.devel:215505 Archived-At: Hello, Paul. On Mon, Jun 05, 2017 at 17:14:37 -0700, Paul Eggert wrote: > >> Elisp code needed to use > >> (message "%s" STR) even before the change you're objecting to, > > Did it? When and why? > Yes, because one can’t pass arbitrary strings to the message function > and expect them to be displayed as-is. This has absolutely nothing to do with the current bug, and I'm sorry if I've discussed the point as though it did. I'm not suggesting arbitrary strings should be messaged without a "%s" format string. What I am arguing against is being required to use _two_ format strings in one message invocation, as (message "%s" (format "..." ...)). This just screams out "not thought through" and is unacceptable. > > Somebody using message to output Lisp will use ' just as I did - and > > suffer the same horrendous problems > Sure, like the “horrendous” problems with %. That's pure sophistry. _Nobody_, excepting the least bright of your students (I'm assuming here that it's not the teaching which is at fault) will have the slightest difficulty with % in message, because it stands out visually. Every format construct (up to Emacs 24) started off with %, and that simplicity and symmetry has now been destroyed. I propose to restore it. By contrast, the current ` and ' are disguised format constructs which look like plain characters. They should become %` and %' to make them explicit and compatible with all the other format constructs. > For example, in Emacs 24 your example, when used with data involving > %: [ .... ] That example from CC Mode, which gave rise to this bug report, did not have and could not have had % signs. If the reverse had been the case, they would have been carefully and correctly coded before even trying the thing out, because I, like everybody else here, know that % introduces format constructs. > > Do you, perhaps, have another strategem for preventing this problem? > Sure: don’t pass arbitrary strings to the message function. In other words, just ignore the problem, and have it hit as many people as it will, without giving them any help. That's not very nice of you. > > How do you propose to prevent such puzzlement and anger in the future > Not by this: > >> (error "Can't find `%s' in %s" thing where))) > >> => (error "Can%'t find %`%s%' in %s" thing where))) > For Emacs code this would likely be a cure worse than the disease, > .... How so? It would make the format constructs explicit, giving maximum control to the hacker. Or do you want to make all the curvy quote stuff as sly and stealthy as possible, so that as few hackers as possible will be aware of it? > .... by causing more puzzlement and anger than it would prevent. How could it cause puzzlement? It's mnemonic and consistent with the other format constructs. > It would make formats significantly harder to read. But only slightly. You seem to be saying that the formats need to be dumbed down for hackers to understand them. I'm sure you're not right, here. > And as Clément mentioned, it would introduce compatibility problems of > its own. Rubbish! What Clément pointed out is that the part of styled_format which counts format constructs and argumnts would need to be modified. This would be trivial. > There is a better way if the primary goal is to avoid quote translation: > (error "Can't find `%s' in %s" thing where))) > => (error "Can’t find ‘%s’ in %s" thing where))) > Compared to %` and %', this is simpler, easier to read, and more > compatible with current and older Emacs versions. Except those characters don't appear on non-Finnish keyboards, hence are difficult to type, and they don't display nicely on all supported environments. These things make that suggestion a non-starter for current purposes. > A downside, though, is that it would involve changing hundreds or > thousands of strings in the Emacs source (just as %` and %' would). There's already a volunteer to do this work, so that's not really a downside at all. > > 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? > Sure, they learn about % after the message function doesn’t work the way > they naively expected. In that respect, % is like ` and '. Only in the same sense that Emacs is like Microsoft's notepad, in that they're both text editors. Only the rawest of beginners will be confused by a % in a format string. That is not the level of experience we expect of our target users. > > There are around 275 calls to message which have a non-literal > > format argument. > Each one stands for possibly many other calls, and we don’t know how > many of these other calls might cause a problem. No, but the number will be small enough for each instance to be dealt with individually. > > The consequences of surreptitious unwanted translation ... > >> It's not surreptitious: it's documented. It may be documented, but it's still surreptitious. It seems intended by its writer to be as hidden as possible, so as to make those using it as unaware as possible of the consequences of its use. If you don't like %` and %', perhaps you could suggest some other way of preventing the nature of ` and ' in format strings from being so obscure. > > And this documentation is useless for preventing the problems. > True, documentation by itself does not prevent programming problems. > However, this doesn’t change the fact that quote translation is > documented. It is not “surreptitious” or “implicit” or “vague” or > “stealthy” or “fuzzy”. It is most definitely implicit, in that there is no indication in the format string that quote translation happens, it is stealthy, in that it goes out of its way to hide its actions. It is vague, in that a hacker who sort of knows message will be permanently unsure which characters in a format string are not literal. This documentation, no matter how good it might be made, will be insufficient to prevent hackers falling into the trap which the code sets. This part of Emacs is badly thought out for this reason: it's an accident waiting to happen. I am proposing to fix it, and have volunteered to do the work. -- Alan Mackenzie (Nuremberg, Germany).