Mercurial > emacs

changeset 42979:7359d6d75a9c

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Minor cleanups.
author Richard M. Stallman <rms@gnu.org>
date Sat, 26 Jan 2002 22:43:53 +0000
parents dcc8ffab2cec
children 6134751ae11f
files lispref/tips.texi
diffstat 1 files changed, 12 insertions(+), 12 deletions(-) [+]
line wrap: on
line diff
--- a/lispref/tips.texi	Sat Jan 26 17:10:34 2002 +0000
+++ b/lispref/tips.texi	Sat Jan 26 22:43:53 2002 +0000
@@ -483,6 +483,17 @@
 a running Emacs.
 
 @item
+Format the documentation string so that it fits in an Emacs window on an
+80-column screen.  It is a good idea for most lines to be no wider than
+60 characters.  The first line should not be wider than 67 characters
+or it will look bad in the output of @code{apropos}.
+
+You can fill the text if that looks good.  However, rather than blindly
+filling the entire documentation string, you can often make it much more
+readable by choosing certain line breaks with care.  Use blank lines
+between topics if the documentation string is long.
+
+@item
 The first line of the documentation string should consist of one or two
 complete sentences that stand on their own as a summary.  @kbd{M-x
 apropos} displays just the first line, and if that line's contents don't
@@ -503,7 +514,7 @@
 cons of A and B.'' in preference to ``Returns the cons of A and B@.''
 Usually it looks good to do likewise for the rest of the first
 paragraph.  Subsequent paragraphs usually look better if each sentence
-has a proper subject.
+is indicative and has a proper subject.
 
 @item
 Write documentation strings in the active voice, not the passive, and in
@@ -527,17 +538,6 @@
 
 @item
 Do not start or end a documentation string with whitespace.
-
-@item
-Format the documentation string so that it fits in an Emacs window on an
-80-column screen.  It is a good idea for most lines to be no wider than
-60 characters.  The first line should not be wider than 67 characters
-or it will look bad in the output of @code{apropos}.
-
-You can fill the text if that looks good.  However, rather than blindly
-filling the entire documentation string, you can often make it much more
-readable by choosing certain line breaks with care.  Use blank lines
-between topics if the documentation string is long.
  
 @item
 @strong{Do not} indent subsequent lines of a documentation string so