emacs-diffs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Emacs-diffs] Changes to emacs/lispref/tips.texi


From: Richard M. Stallman
Subject: [Emacs-diffs] Changes to emacs/lispref/tips.texi
Date: Sat, 26 Jan 2002 17:43:54 -0500

Index: emacs/lispref/tips.texi
diff -c emacs/lispref/tips.texi:1.40 emacs/lispref/tips.texi:1.41
*** emacs/lispref/tips.texi:1.40        Mon Nov 12 21:20:53 2001
--- emacs/lispref/tips.texi     Sat Jan 26 17:43:53 2002
***************
*** 483,488 ****
--- 483,499 ----
  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,509 ****
  cons of A and B.'' in preference to ``Returns the cons of A and 
address@hidden''
  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.
  
  @item
  Write documentation strings in the active voice, not the passive, and in
--- 514,520 ----
  cons of A and B.'' in preference to ``Returns the cons of A and 
address@hidden''
  Usually it looks good to do likewise for the rest of the first
  paragraph.  Subsequent paragraphs usually look better if each sentence
! is indicative and has a proper subject.
  
  @item
  Write documentation strings in the active voice, not the passive, and in
***************
*** 527,543 ****
  
  @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
--- 538,543 ----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]