]> git.donarmstrong.com Git - lilypond.git/blob - Documentation/user/writing-texinfo.txt
Minor policy.
[lilypond.git] / Documentation / user / writing-texinfo.txt
1 DOCUMENTATION FORMATTING
2 ------------------------
3
4 The language is called texinfo; you can see its manual here:
5 http://www.gnu.org/software/texinfo/manual/texinfo/
6
7 However, you don't need to read those docs.  The most important
8 thing to notice is that text is text.  If you see a mistake in the
9 text, you can fix it.  If you want to change the order of
10 something, you can cut-and-paste that stuff into a new location.
11
12
13 %%%%% SECTIONING COMMANDS
14
15 Most of the manual operates at the
16         @node Foo
17         @subsubsection Foo
18 level.  Sections are created with
19         @node Foo
20         @subsection Foo
21 commands.
22
23 * sectioning commands (@node and @section) must not appear inside
24   an @ignore.  Separate those commands with a space, ie @n ode.
25
26
27
28 %%%%% LILYPOND FORMATTING
29
30 * Use two spaces for indentation in lilypond examples.  (no tabs)
31
32 * All text strings should be prefaced with #.  LilyPond does not
33   strictly require this, but it is helpful to get users accustomed
34   to this scheme construct.  ie
35     \set Staff.instrumentName = #"cello"
36
37 * All engravers should have double-quotes around them:
38     \consists "Spans_arpeggio_engraver"
39   Again, LilyPond does not strictly require this, but it is a
40   useful standard to follow.
41
42 * Examples should end with a complete bar if possible.
43
44 * If possible, only write one bar per line.  The notes on each
45   line should be an independent line -- tweaks should occur on
46   their own line if possible.
47   Bad:
48     \override textscript #'padding = #3 c1^"hi"
49   Good:
50     \override textscript #'padding = #3
51     c1^"hi"
52
53 * LilyPond input should be produced via
54     @lilypond[verbatim,quote,ragged-right]
55   with `fragment' and `relative=2' optional.
56
57   Examples about page layout may alter the quote/ragged-right
58   options.  Omitting `verbatim' is not allowed except for special
59   circumstances.
60
61 * Inspirational headwords are produced with
62   @lilypondfile[quote,ragged-right,line-width=16\cm,staffsize=16]
63   {pitches-headword.ly}
64
65 * LSR snippets are linked with
66   @lilypondfile[verbatim,lilyquote,ragged-right,texidoc]
67   {filename.ly}
68
69 * Avoid long stretches of input code.  Noone is going to read them
70   in print.  Please create a smaller example.  (the smaller
71   example does not need to be minimal, however)
72
73 * Specify durations for at least the first note of every bar.
74
75 * If possible, end with a complete bar.
76
77 * If you only have one bar per line, omit bar checks.  If you
78   put more than one bar per line (not recommended), then include
79   bar checks.
80
81 * If you want to work on an example outside of the manual (for
82   easier/faster processing), use this header:
83
84 \paper {
85   #(define dump-extents #t)
86   indent = 0\mm
87   line-width = 160\mm - 2.0 * 0.4\in
88   ragged-right = ##t
89   force-assignment = #""
90   line-width = #(- line-width (* mm  3.000000))
91 }
92
93 \layout {
94 }
95
96   You may not change any of these values.  If you are making an
97   example demonstrating special \paper{} values, contact the
98   Documentation Editor.
99
100
101 %%%%% TEXT FORMATTING
102
103 * Lines should be less than 72 characters long.  (I personally
104   recommend writing with 66-char lines, but don't bother modifying
105   existing material.)
106
107 * Do not use tabs.
108
109 * Do not use spaces at the beginning of a line (except in @example
110   or @verbatim environments), and do not use more than a single
111   space between words.  `makeinfo' copies the input lines verbatim
112   without removing those spaces.
113
114 * Use two spaces after a period.
115
116 * In examples of syntax, use @var{musicexpr} for a music
117   expression.
118
119 * Variables or numbers which consist of a single character
120   (probably followed by a punctuation mark) should be tied
121   properly, either to the previous or the next word.  Example:
122
123       The variable@tie{}@var{a} ...
124
125 * To get consistent indentation in the DVI output it is better to
126   avoid the @verbatim environment.  Use the @example environment
127   instead if possible, but without extraneous indentation.  For
128   example, this
129
130     @example
131       foo {
132         bar
133       }
134     @end example
135
136   should be replaced with
137
138     @example
139     foo {
140       bar
141     }
142     @end example
143
144   where `@example' starts the line (without leading spaces).
145
146 * Do not compress the input vertically; this is, do not use
147
148     Beginning of logical unit
149     @example
150     ...
151     @end example
152     continuation of logical unit
153
154   but
155
156     Beginning of logical unit
157
158     @example
159     ...
160     @end example
161
162     @noindent
163     continuation of logical unit
164
165   This makes it easier to avoid forgetting the `@noindent'.  Only
166   use @noindent if the material is discussing the same material;
167   new material should simply begin without anything special on the
168   line above it.
169
170 * in @itemize use @item on a separate line like this:
171   @itemize
172   @item
173   Foo
174
175   @item
176   Bar
177
178   Do not use @itemize @bullet.
179
180 * To get LilyPond version, use @version{} (this does not work inside
181   LilyPond snippets).  If you write "@version{}" (enclosed with
182   quotes), or generally if @version{} is not followed by a space,
183   enclose it with
184
185   @w{ ... }
186
187   e.g.
188
189   @w{"@version{}"}
190
191   to prevent an ugly line break in PDF output.
192
193
194 %%%%% SYNTAX SURVEY
195
196 @c - single line comments
197   "@c NOTE:" is a comment which should remain in the final
198   version.  (gp only command ;)
199 @ignore ... @end ignore - multi-line comment
200
201 @cindex - General index. Please add as many as you can.  Don't
202   capitalize the first word.
203 @funindex - is for a \lilycommand.
204
205 @example ... @end ignore - example text that should be set as a
206   blockquote.  Any {} must be escaped with @{ }@
207 @itemize @item A @item B ... @end itemize - for bulleted lists.
208   Do not compress vertically like this.
209
210 @code{} - typeset in a tt-font. Use for actual lilypond code or
211   property/context names.
212 @notation{} - refers to pieces of notation, e.g.
213   "@notation{cres.}".  Also use to specific lyrics ("the
214   @notation{A - men} is centered")
215 @q{} - Single quotes. Used for `vague' terms.
216 @qq{} - Double quotes.  Used for actual quotes ("he said").
217
218 @tie{} - Variables or numbers which consist of a single character
219   (probably followed by a punctuation mark) should be tied
220   properly, either to the previous or the next word.  Example:
221     "The letter@tie{}@q{I} is skipped"
222
223 @var - Use for variables.
224 @warning{} - produces a "Note: " box. Use for important messages.
225
226 @bs - Generates a backslash inside @warning.
227     Any `\' used inside @warning (and @q or @qq) must be written as `@bs{}' 
228     (texinfo would also allow \\, but this breaks with PDF output).
229
230
231
232 %%%%% OTHER TEXT CONCERNS
233
234 * References must occur at the end of a sentence, for more
235   information see @ref{the texinfo manual}.  Ideally this should
236   also be the final sentence of a paragraph, but this is not
237   required.  Any link in a doc section must be duplicated in the
238   @seealso section at the bottom.
239
240 * Introducing examples must be done with
241      . (ie finish the previous sentence/paragaph)
242      : (ie `in this example:')
243      , (ie `may add foo with the blah construct,')
244   The old "sentence runs directly into the example" method is not
245   allowed any more.
246
247 * Abbrevs in caps, e.g., HTML, DVI, MIDI, etc.
248
249 * Colon usage
250
251   1. To introduce lists
252   2. When beginning a quote: "So, he said,..."
253      This usage is rarer.  Americans often just use a comma.
254   3. When adding a defining example at the end of a sentence.
255
256 * Non-ASCII characters which are in utf-8 should be directly used;
257   this is, don't say `Ba@ss{}tuba' but `Baßtuba'.  This ensures that
258   all such characters appear in all output formats.
259