GNU bug report logs -
#40011
Remove unnecessary abbreviations from documentation
Previous Next
Reported by: Stefan Kangas <stefan <at> marxist.se>
Date: Tue, 10 Mar 2020 13:55:01 UTC
Severity: wishlist
Fixed in version 27.1
Done: Stefan Kangas <stefan <at> marxist.se>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40011 in the body.
You can then email your comments to 40011 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
rms <at> gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#40011
; Package
emacs
.
(Tue, 10 Mar 2020 13:55:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Kangas <stefan <at> marxist.se>
:
New bug report received and forwarded. Copy sent to
rms <at> gnu.org, bug-gnu-emacs <at> gnu.org
.
(Tue, 10 Mar 2020 13:55:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
X-Debbugs-CC: Richard Stallman <rms <at> gnu.org>
Writing for Computer Science (2004) by Justin Zobel says:
"It is often tempting to use abbreviations such as 'no.', 'i.e.',
'e.g.' 'c.f.' and 'w.r.t.' These save little space on the page,
but slow readers down. It is almost always desirable to expand
these abbreviations, to 'number', 'that is', 'for example',
'compared with' (or more accurately 'in contrast to', since that
is the sense in which 'c.f.' should be used), and 'with respect
to', or synonyms of these expressions. Where such abbreviations
are used, the punctuation should be as if the expanded form were
used. Also consider expanding abbreviations such as 'Fig.' and
'Alg.' and don't use concoctions such as '1st' or '2nd'. Months
should not be abbreviated. Make sure that all abbreviations and
acronyms are explained when they are first used." (page 57)
Please consider removing the following acronyms from the
documentation, both the manual(s) and doc strings:
1. no. ("number")
2. e.g. ("for example")
3. i.e. ("that is", "namely", etc.)
4. c.f. ("in contrast to", "compared with", etc.)
5. w.r.t. ("with respect to")
Please also consider adding a guideline to avoid them where possible.
I think we should not do this in a blanket fashion, however, but treat
each case individually. For example, it seems to me that it's a good
idea to be much more lenient in tables, where space may be a serious
concern.
If anyone has any suggestions for other abbreviations that could
perhaps be avoided, please add them to the list. Any comments?
Best regards,
Stefan Kangas
PS. For further background, see Bug#39778:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39778
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40011
; Package
emacs
.
(Tue, 10 Mar 2020 14:51:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 40011 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Tue, 10 Mar 2020 14:54:25 +0100
> Cc: richard stallman <rms <at> gnu.org>
>
> Please consider removing the following acronyms from the
> documentation, both the manual(s) and doc strings:
>
> 1. no. ("number")
> 2. e.g. ("for example")
> 3. i.e. ("that is", "namely", etc.)
> 4. c.f. ("in contrast to", "compared with", etc.)
> 5. w.r.t. ("with respect to")
Let's not be too extreme: I'm against removing "e.g." and "i.e." at
the least.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40011
; Package
emacs
.
(Mon, 27 Apr 2020 06:06:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 40011 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Please consider removing the following acronyms from the
>> documentation, both the manual(s) and doc strings:
>>
>> 1. no. ("number")
>> 2. e.g. ("for example")
>> 3. i.e. ("that is", "namely", etc.)
>> 4. c.f. ("in contrast to", "compared with", etc.)
>> 5. w.r.t. ("with respect to")
>
> Let's not be too extreme: I'm against removing "e.g." and "i.e." at
> the least.
There are many such instances to get right, so maybe we can find a way
forward which avoids changing all of them.
How about adding something along the lines of the attached patch, and
leave it at that? Would that be acceptable?
Best regards,
Stefan Kangas
[0001-Recommend-avoiding-unnecessary-abbreviations-in-doc.patch (text/x-diff, inline)]
From a44c03f6a2b2b98b34b4c7836e3291fd2c458190 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefankangas <at> gmail.com>
Date: Mon, 27 Apr 2020 07:53:10 +0200
Subject: [PATCH] Recommend avoiding unnecessary abbreviations in doc
* doc/lispref/tips.texi (Documentation Tips): Recommend avoiding
unnecessary abbreviations. (Bug#40011)a
---
doc/lispref/tips.texi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/doc/lispref/tips.texi b/doc/lispref/tips.texi
index 3b8da35b6c..382e6d7c61 100644
--- a/doc/lispref/tips.texi
+++ b/doc/lispref/tips.texi
@@ -820,6 +820,12 @@ Documentation Tips
most cases, the meaning is clear with just ``if''. Otherwise, try to
find an alternate phrasing that conveys the meaning.
+@item
+Avoid abbreviations like ``e.g.'' (for ``for example''), ``i.e.'' (for
+``that is''), ``no.'' (for ``number''), ``c.f.'' (for ``in contrast
+to'') and ``w.r.t.'' (for ``with respect to''). It is almost always
+both more clear and easier to read the expanded version.
+
@item
When a command is meaningful only in a certain mode or situation,
do mention that in the documentation string. For example,
--
2.26.2
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40011
; Package
emacs
.
(Mon, 27 Apr 2020 14:40:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 40011 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefan <at> marxist.se>
> Cc: 40011 <at> debbugs.gnu.org, rms <at> gnu.org
> Date: Mon, 27 Apr 2020 08:05:34 +0200
>
> > Let's not be too extreme: I'm against removing "e.g." and "i.e." at
> > the least.
>
> There are many such instances to get right, so maybe we can find a way
> forward which avoids changing all of them.
>
> How about adding something along the lines of the attached patch, and
> leave it at that? Would that be acceptable?
> [...]
> +@item
> +Avoid abbreviations like ``e.g.'' (for ``for example''), ``i.e.'' (for
> +``that is''), ``no.'' (for ``number''), ``c.f.'' (for ``in contrast
> +to'') and ``w.r.t.'' (for ``with respect to''). It is almost always
> +both more clear and easier to read the expanded version.
It would be fine with me, but there are a lot of pedants out there,
and I'd rather we avoided bug reports telling us "why don't you do as
you say and remove all the e.g.'s from your own manuals." I'd like to
avoid the endless disputes such bug reports tend to cause.
So could you make the above even less definitive, either by saying
"Try to avoid using abbreviations like ... as much as possible."
Maybe even add a footnote saying something like "We do occasionally
use these, but try not to overdo it.".
OK?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40011
; Package
emacs
.
(Mon, 27 Apr 2020 16:11:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 40011 <at> debbugs.gnu.org (full text, mbox):
> There are many such instances to get right, so maybe we can find a way
> forward which avoids changing all of them.
>
> How about adding something along the lines of the attached patch, and
> leave it at that? Would that be acceptable?
(minor nit)
* "like" -> "such as"
* "more clear" -> "clearer"
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40011
; Package
emacs
.
(Mon, 27 Apr 2020 16:22:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 40011 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
>> There are many such instances to get right, so maybe we can find a way
>> forward which avoids changing all of them.
>>
>> How about adding something along the lines of the attached patch, and
>> leave it at that? Would that be acceptable?
>
> (minor nit)
>
> * "like" -> "such as"
> * "more clear" -> "clearer"
Thanks. As you might know, English is a second language for me so I
really appreciate this kind of input.
Best regards,
Stefan Kangas
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40011
; Package
emacs
.
(Mon, 27 Apr 2020 16:42:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 40011 <at> debbugs.gnu.org (full text, mbox):
> > (minor nit)
> >
> > * "like" -> "such as"
> > * "more clear" -> "clearer"
>
> Thanks. As you might know, English is a
> second language for me so I really
> appreciate this kind of input.
You're welcome. And this is very minor.
Colloquially many (most?) people use "like"
when they really mean "such as".
The difference is that "such as" includes
those explicit examples - it says "these
and others (like them)"; whereas "like"
says "things similar to these things".
"Like" doesn't explicitly include those
things; it says to use them to get an idea
of what kind of things might be included.
1. The award was given to people like
George Washington.
2. The award was given to people such as
George Washington.
#1 says that people with characteristics
like GW got the award. #2 says that GW is
an example of the people who got the award.
In case #2, GW got the award.
---
There's nothing wrong with "more clear".
But "clearer" is usually clearer. ;-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40011
; Package
emacs
.
(Mon, 27 Apr 2020 17:09:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 40011 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> It would be fine with me, but there are a lot of pedants out there,
> and I'd rather we avoided bug reports telling us "why don't you do as
> you say and remove all the e.g.'s from your own manuals." I'd like to
> avoid the endless disputes such bug reports tend to cause.
>
> So could you make the above even less definitive, either by saying
>
> "Try to avoid using abbreviations like ... as much as possible."
>
> Maybe even add a footnote saying something like "We do occasionally
> use these, but try not to overdo it.".
>
> OK?
Yes, that makes sense, thanks. Please see the attached patch with
your suggestions (and Drew's input) incorporated.
Best regards,
Stefan Kangas
[0001-Recommend-to-avoid-unnecessary-abbreviations-in-doc.patch (text/x-diff, inline)]
From f9ece19a97066e4861f4b58631a588d30aa7999b Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefankangas <at> gmail.com>
Date: Mon, 27 Apr 2020 07:53:10 +0200
Subject: [PATCH] Recommend to avoid unnecessary abbreviations in doc
* doc/lispref/tips.texi (Documentation Tips): Recommend to avoid
unnecessary abbreviations. (Bug#40011)
---
doc/lispref/tips.texi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/doc/lispref/tips.texi b/doc/lispref/tips.texi
index 3b8da35b6c..5b09b2ccea 100644
--- a/doc/lispref/tips.texi
+++ b/doc/lispref/tips.texi
@@ -820,6 +820,14 @@ Documentation Tips
most cases, the meaning is clear with just ``if''. Otherwise, try to
find an alternate phrasing that conveys the meaning.
+@item
+Try to avoid using abbreviations such as ``e.g.'' (for ``for
+example''), ``i.e.'' (for ``that is''), ``no.'' (for ``number''),
+``c.f.'' (for ``in contrast to'') and ``w.r.t.'' (for ``with respect
+to'') as much as possible. It is almost always clearer and easier to
+read the expanded version.@footnote{We do use these occasionally, but
+try not to overdo it.}
+
@item
When a command is meaningful only in a certain mode or situation,
do mention that in the documentation string. For example,
--
2.26.2
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40011
; Package
emacs
.
(Mon, 27 Apr 2020 18:32:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 40011 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefan <at> marxist.se>
> Cc: 40011 <at> debbugs.gnu.org, rms <at> gnu.org
> Date: Mon, 27 Apr 2020 19:08:21 +0200
>
> > So could you make the above even less definitive, either by saying
> >
> > "Try to avoid using abbreviations like ... as much as possible."
> >
> > Maybe even add a footnote saying something like "We do occasionally
> > use these, but try not to overdo it.".
> >
> > OK?
>
> Yes, that makes sense, thanks. Please see the attached patch with
> your suggestions (and Drew's input) incorporated.
Thanks, this is fine by me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40011
; Package
emacs
.
(Tue, 28 Apr 2020 02:48:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 40011 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> "Try to avoid using abbreviations like ... as much as possible."
> Maybe even add a footnote saying something like "We do occasionally
> use these, but try not to overdo it.".
We could even say, "We intend to replace these abbreviations,
but we are not in a desperate hurry."
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40011
; Package
emacs
.
(Tue, 28 Apr 2020 02:51:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 40011 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> How about adding something along the lines of the attached patch, and
> leave it at that? Would that be acceptable?
I agree with it.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40011
; Package
emacs
.
(Thu, 30 Apr 2020 16:06:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 40011 <at> debbugs.gnu.org (full text, mbox):
close 40011 27.1
thanks
Eli Zaretskii <eliz <at> gnu.org> writes:
> Thanks, this is fine by me.
Now pushed to emacs-27 as commit 1d477a0fec. Closing.
Best regards,
Stefan Kangas
bug marked as fixed in version 27.1, send any further explanations to
40011 <at> debbugs.gnu.org and Stefan Kangas <stefan <at> marxist.se>
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org
.
(Thu, 30 Apr 2020 16:06:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 29 May 2020 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 25 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.