[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs 26.1 release branch created
From: |
Paul Eggert |
Subject: |
Re: Emacs 26.1 release branch created |
Date: |
Sun, 24 Sep 2017 11:13:06 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 |
Alan Mackenzie wrote:
Putting a single output
operation through two `format'-like operations is bizarre and
extravagant. It's not something we should encourage.
It's not bizarre; it's routine in Emacs Lisp code. And it's not extravagant: the
loss in efficiency for messages is tiny, and is not something users have noticed
or complained about.
By contrast, binding a controlling variable around an operation is the
standard Emacs way of doing such things.
It's standard for other things, but it's definitely not standard here. The Emacs
source code never does it this way.
How many such instances are there in the code anyway?
There are about 400 instances of '(message "%s"' or '(error "%s"' in the Emacs
source code. For decades this has been common practice when an Elisp programmer
wants to avoid translation or formatting in the argument to 'message'-like
functions. It's not that easy to count how many of the 400 instances are for
quotes as opposed to being for other things, but I'd guess dozens.
This would need fleshing out with something like "To inhibit
or influence this translation of ASCII quotes, see text-quoting-style".
Sure, that's easy. Revised proposal attached.
The "boilerplate" you want to replace is short and to the point,
It is not short; it's discursive and it gets in the way. In your proposal, it's
about ten lines of boilerplate for each affected function, boilerplate that is
about as long as the main function description itself. We should move most of
this boilerplate to a common section, and briefly allude to it in each affected
function. This will give us room to expand on the issue in the common section,
which I've done in my proposal - it has about twenty lines discussing the issue,
and this is shorter and provides more useful info than repeating ten lines in
multiple places.
A further general point about this bit of doc is its rather strange use
of the verb "generate".
Also easy; the revised proposal (attached) uses "translates to" instead of
"generates".
0001-Improve-text-quoting-style-doc-in-lispref.patch
Description: Text Data
- Re: Emacs 26.1 release branch created, (continued)
- Re: Emacs 26.1 release branch created, Paul Eggert, 2017/09/19
- Re: Emacs 26.1 release branch created, John Wiegley, 2017/09/20
- Re: Emacs 26.1 release branch created, Alan Mackenzie, 2017/09/21
- Re: Emacs 26.1 release branch created, Paul Eggert, 2017/09/22
- Re: Emacs 26.1 release branch created, John Wiegley, 2017/09/22
- Re: Emacs 26.1 release branch created, Alan Mackenzie, 2017/09/22
- Re: Emacs 26.1 release branch created, John Wiegley, 2017/09/22
- Re: Emacs 26.1 release branch created, Paul Eggert, 2017/09/22
- Re: Emacs 26.1 release branch created, Alan Mackenzie, 2017/09/24
- Re: Emacs 26.1 release branch created,
Paul Eggert <=
- Re: Emacs 26.1 release branch created, Alan Mackenzie, 2017/09/24
- Re: Emacs 26.1 release branch created, Eli Zaretskii, 2017/09/22
- Re: Emacs 26.1 release branch created, Alan Mackenzie, 2017/09/22
- Re: Emacs 26.1 release branch created, Stefan Monnier, 2017/09/22
- Re: Emacs 26.1 release branch created, John Wiegley, 2017/09/22
- Re: Emacs 26.1 release branch created, Alan Mackenzie, 2017/09/22
- Re: Emacs 26.1 release branch created, John Wiegley, 2017/09/22
- Re: Emacs 26.1 release branch created, Alan Mackenzie, 2017/09/22
- Re: Emacs 26.1 release branch created, Alan Mackenzie, 2017/09/24
- Re: Emacs 26.1 release branch created, Paul Eggert, 2017/09/24