From: Paul Eggert <eggert@cs.ucla.edu>
To: Alan Mackenzie <acm@muc.de>
Cc: 23425@debbugs.gnu.org, emacs-devel@gnu.org
Subject: bug#23425: master branch: `message' wrongly corrupts ' to curly quote.
Date: Mon, 5 Jun 2017 11:19:06 -0700 [thread overview]
Message-ID: <ac90b979-6a37-29c4-03b3-6322ac2cc11a__23486.0425153331$1496686834$gmane$org@cs.ucla.edu> (raw)
In-Reply-To: <20170605162737.GA30946@acm.fritz.box>
On 06/05/2017 09:27 AM, Alan Mackenzie wrote:
> Can you give an example of something which might need two strings?
Suppose the same string is used for both messages and documentation.
You're proposing %` in the former where ` is in the latter, so we would
need distinct strings.People cut and paste between messages and doc
strings, and it's possible there's even code that does this (I haven't
checked). Using different quoting notations for the two kinds of strings
will cause confusion and problems.
> 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. 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 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.
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)))
These changes will adversely affect code readability, and this will have
a maintenance cost in the long run -- not just to whoever makes the
hundreds or thousands of changes, but to everybody who has to read the
code afterwards.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.
> _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.
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, and it'd
still need (message "%s" STR) even if the change were reverted.
> 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 '. In hindsight,
the message function should have had a better API. Hindsight is
wonderful....
next prev parent reply other threads:[~2017-06-05 18:19 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-02 14:55 bug#23425: master branch: `message' wrongly corrupts ' to curly quote Alan Mackenzie
2016-05-02 16:25 ` Lars Ingebrigtsen
2016-05-02 16:41 ` Drew Adams
2016-05-02 17:53 ` Paul Eggert
2016-05-02 19:10 ` Alan Mackenzie
2016-05-03 15:17 ` Paul Eggert
2016-05-03 16:36 ` Drew Adams
2016-05-03 16:59 ` Eli Zaretskii
2016-05-03 15:38 ` Eli Zaretskii
2016-05-03 16:27 ` Alan Mackenzie
2016-05-03 16:55 ` Eli Zaretskii
2016-05-03 20:03 ` Alan Mackenzie
2016-05-03 20:49 ` Paul Eggert
2016-05-04 15:32 ` Eli Zaretskii
2016-05-04 16:48 ` Alan Mackenzie
2016-05-04 17:03 ` Eli Zaretskii
2016-05-04 17:37 ` Josh
2016-05-04 19:05 ` Eli Zaretskii
2016-05-04 18:04 ` Alan Mackenzie
2016-05-04 18:39 ` Paul Eggert
2016-05-04 18:57 ` Alan Mackenzie
2016-05-04 19:02 ` John Wiegley
2016-05-04 21:34 ` Paul Eggert
2016-05-04 21:50 ` Paul Eggert
2016-05-04 23:49 ` Paul Eggert
2016-05-05 15:51 ` Eli Zaretskii
2016-05-10 14:41 ` Paul Eggert
2017-05-31 1:07 ` Glenn Morris
2017-05-31 1:42 ` Paul Eggert
2017-05-31 21:24 ` Alan Mackenzie
2017-05-31 23:26 ` Paul Eggert
2017-06-02 21:02 ` Alan Mackenzie
2017-06-02 21:15 ` Dmitry Gutov
2017-06-03 21:10 ` Alan Mackenzie
[not found] ` <20170603211010.GD2130@acm.fritz.box>
2017-06-03 21:32 ` Dmitry Gutov
2017-06-02 21:47 ` Paul Eggert
2017-06-03 0:13 ` Glenn Morris
2017-06-03 21:01 ` Alan Mackenzie
2017-06-03 20:53 ` Alan Mackenzie
[not found] ` <20170603205331.GA2130@acm.fritz.box>
2017-06-04 21:01 ` Paul Eggert
2017-06-05 16:27 ` Alan Mackenzie
[not found] ` <20170605162737.GA30946@acm.fritz.box>
2017-06-05 18:19 ` Paul Eggert [this message]
[not found] ` <ac90b979-6a37-29c4-03b3-6322ac2cc11a@cs.ucla.edu>
2017-06-05 18:31 ` Andreas Schwab
2017-06-05 20:37 ` Alan Mackenzie
[not found] ` <20170605203753.GB30946@acm.fritz.box>
2017-06-05 21:05 ` Clément Pit-Claudel
2017-06-07 16:50 ` Alan Mackenzie
2017-06-07 19:29 ` Clément Pit-Claudel
2017-06-06 0:14 ` Paul Eggert
2017-06-06 8:21 ` Andreas Schwab
[not found] ` <mvmtw3tsf05.fsf@suse.de>
2017-06-06 12:24 ` Clément Pit-Claudel
[not found] ` <fa92f34f-982b-e9a5-be21-188e694e38d9@gmail.com>
2017-06-06 13:55 ` Yuri Khan
[not found] ` <CAP_d_8X7V_G4g7emn_EPd_YYPKu2HfnDE+Q3FOPMGXpB4sEYSw@mail.gmail.com>
2017-06-06 18:21 ` Clément Pit-Claudel
2017-06-06 18:59 ` Yuri Khan
[not found] ` <CAP_d_8X5OBsQQ=0+dj-qYFV3yEC4WZVMpyRw1KyiM0tvJUNFMw@mail.gmail.com>
2017-06-06 19:39 ` Clément Pit-Claudel
[not found] ` <10515b89-1c60-227e-ff3d-3127f59c0daf@gmail.com>
2017-06-07 4:57 ` Eli Zaretskii
2017-06-06 23:09 ` Paul Eggert
2017-06-07 7:44 ` Andreas Schwab
2017-06-07 18:17 ` Paul Eggert
2017-06-08 8:04 ` Andreas Schwab
2017-06-07 13:27 ` Drew Adams
2017-06-07 19:13 ` Alan Mackenzie
2017-06-07 19:27 ` Clément Pit-Claudel
[not found] ` <966db090-4aa1-231c-ef5a-370ece8905d1@gmail.com>
2017-06-07 19:33 ` Dmitry Gutov
2017-06-07 19:51 ` Alan Mackenzie
2017-06-07 20:33 ` Alan Mackenzie
2017-06-07 23:28 ` Paul Eggert
2017-06-08 17:34 ` Alan Mackenzie
2017-06-08 20:17 ` Paul Eggert
2017-06-09 19:41 ` Alan Mackenzie
2017-06-09 20:17 ` Drew Adams
2017-06-09 20:38 ` Alan Mackenzie
2017-06-09 21:05 ` Drew Adams
2017-06-09 21:44 ` Paul Eggert
2017-06-09 22:51 ` Drew Adams
2017-06-10 0:20 ` Paul Eggert
2017-06-10 10:01 ` Alan Mackenzie
2017-06-10 10:52 ` David Engster
2017-06-10 11:48 ` Eli Zaretskii
2017-06-10 13:01 ` Alan Mackenzie
2017-06-10 13:39 ` Eli Zaretskii
2017-06-11 10:03 ` Alan Mackenzie
2017-06-11 14:37 ` Eli Zaretskii
2017-06-10 15:28 ` Dmitry Gutov
2017-06-01 16:56 ` Glenn Morris
2017-06-03 21:07 ` Alan Mackenzie
2016-05-04 18:46 ` John Wiegley
2016-05-04 20:23 ` Dmitry Gutov
2016-05-04 21:15 ` John Wiegley
2016-05-04 22:19 ` Lars Ingebrigtsen
2016-05-05 7:12 ` Andreas Schwab
2016-05-05 17:05 ` Eli Zaretskii
2016-05-05 8:06 ` Alan Mackenzie
2016-05-05 17:06 ` Eli Zaretskii
2016-05-05 23:46 ` John Wiegley
2016-05-06 8:54 ` Nicolas Petton
2016-05-04 19:08 ` Eli Zaretskii
2016-05-04 21:49 ` Andreas Schwab
2017-06-09 20:31 ` Glenn Morris
2017-06-10 7:08 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='ac90b979-6a37-29c4-03b3-6322ac2cc11a__23486.0425153331$1496686834$gmane$org@cs.ucla.edu' \
--to=eggert@cs.ucla.edu \
--cc=23425@debbugs.gnu.org \
--cc=acm@muc.de \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).