they also stem from attempting to find the most effective use of
limited documentation help.
+Before undertaking any large documentation work, contributors are
+encouraged to contact the @ref{Meisters, Documentation Meister}.
+
@node Documentation suggestions
@section Documentation suggestions
@enumerate
@item
-Tell us where the addition should be placed. Please include both
+Tell us where the addition should be placed. Please include both
the section number and title (i.e. "LM 2.13 Printing lyrics").
@item
@item
A formal patch to the source code is @emph{not} required; we can
-take care of the technical details. Here is an example of a
-perfect documentation report:
+take care of the technical details.
+
+@item
+Send the suggestions to the @code{bug-lilypond} mailing list as
+discussed in @rweb{Contact}.
+
+@item
+Here is an example of a perfect documentation report:
@verbatim
-To: lilypond-devel@gnu.org
+To: bug-lilypond@gnu.org
From: helpful-user@example.net
Subject: doc addition
@subheading Larger contributions
To replace large sections of the documentation, the guidelines are
-stricter. We cannot remove parts of the current documentation
+stricter. We cannot remove parts of the current documentation
unless we are certain that the new version is an improvement.
@enumerate
@item
-Ask on the lilypond-devel maillist if such a rewrite is necessary;
+Ask on the lilypond-devel mailing list if such a rewrite is necessary;
somebody else might already be working on this issue!
@item
@end enumerate
Once you have followed these guidelines, please send a message to
-lilypond-devel with your documentation submissions. Unfortunately
-there is a strict “no top-posting” check on the mailist; to avoid
+lilypond-devel with your documentation submissions. Unfortunately
+there is a strict “no top-posting” check on the mailing list; to avoid
this, add:
> I'm not top posting.
@itemize
@item
-Please leave two blank lines above a @@node; this makes it
+Please leave two blank lines above a @code{@@node}; this makes it
easier to find sections in texinfo.
@item
-Sectioning commands (@@node and @@section) must not appear
-inside an @@ignore. Separate those commands with a space, ie @@n
-ode.
+Do not use any @code{@@} commands for a @code{@@node}. They may be
+used for any @code{@@sub...} sections or headings however.
+
+@example
+not:
+@@node @@code@{Foo@} Bar
+@@subsection @@code@{Foo@} Bar
+
+but instead:
+@@node Foo Bar
+@@subsection @@code@{Foo@} Bar
+@end example
+
+@item
+With the exception of @code{@@} commands, the section name must
+match the node name exactly.
+
+@item
+No commas may be used in the node names.
+
+@item
+If a heading is desired without creating a @code{@@node}, please use
+the following:
+
+@example
+@@subheading Foo
+@end example
+
+@item
+Sectioning commands (@code{@@node} and @code{@@section}) must not appear
+inside an @code{@@ignore}. Separate those commands with a space, ie
+@code{@@n}@tie{}@code{ode}.
@end itemize
@itemize
@item
-Use two spaces for indentation in lilypond examples. (no
-tabs)
+Most LilyPond examples throughout the documentation can be produced
+with:
-@item
-All text strings should be prefaced with #. LilyPond does
-not strictly require this, but it is helpful to get users
-accustomed to this scheme construct. ie @code{\set
-Staff.instrumentName = #"cello"}
+@example
+@@lilypond[verbatim,quote,relative=1]
+@end example
-@item
-All engravers should have double-quotes around them:
+or
@example
-\consists "Spans_arpeggio_engraver"
+@@lilypond[verbatim,quote,relative=2]
@end example
-Again, LilyPond does not strictly require this, but it is a useful
-standard to follow.
+If using any combination of @code{\header@{@}}, @code{\score@{@}} or
+@code{\layout@{@}} in your example, then you must omit the
+@code{relative} variable and either use absolute entry mode or an
+explicit @code{\relative@{@}} construction.
-@item
-If possible, only write one bar per line.
+If using @code{\book@{@}} in your example then you must also omit the
+@code{relative} variable and either use absolute entry mode or an
+explicit @code{\relative@{@}} construction. However, you must also
+include the @code{papersize=X} variable, where @code{X} is a defined
+paper size from within @file{scm/paper.scm}. This is to avoid the
+default @code{a4} paper size being used and leaving too much unnecessary
+whitespace and potentially awkward page breaks in the PDFs.
-@item
-If you only have one bar per line, omit bar checks. If you
-must put more than one bar per line (not recommended), then include bar
-checks.
+The preferred @code{papersize}s are @code{a5}, @code{a6} or
+@code{a8landscape}.
-@item
-Tweaks should, if possible, also occur on their own line.
-Bad:
+@code{a8landscape} works best for a single measure with a single title
+and/or single @code{tagline}:
@example
-\override textscript #'padding = #3 c1^"hi"
+@@lilypond[papersize=a8landscape,verbatim]
+\book @{
+ \header @{
+ title = "A scale in LilyPond"
+ @}
+ \relative @{
+ c d e f
+ @}
+@}
+@@end lilypond
@end example
-Good:
+and can also be used to easily show features that require page breaks
+(i.e. page numbers) without taking large amounts of space within the
+documentation. Do not use the @code{quote} option with this paper size.
-@example
-\override textscript #'padding = #3
-c1^"hi"
-@end example
+@code{a5} or @code{a6} paper sizes are best used for examples that have
+more than two measures of music or require multiple staves (i.e. to
+illustrate cross-staff features, RH and LH parts etc.) and where
+@code{\book@{@}} constructions are required or where @code{a8landscape}
+produces an example that is too cramped. Depending on the example the
+@code{quote} option may need to be omitted.
+
+In rare cases, other options may be used (or omitted), but ask first.
@item
-Most LilyPond input should be produced with:
+Please avoid using extra spacing either after or within the
+@code{@@lilypond} parameters.
@example
-@@lilypond[verbatim,quote,relative=2]
+not: @@lilypond [verbatim, quote, relative=1]
+but instead: @@lilypond[verbatim,quote,relative=1]
@end example
-@noindent
-or
+@item
+Inspirational headwords are produced with:
@example
-@@lilypond[verbatim,quote,relative=1]
+@@lilypondfile[quote,ragged-right,line-width=16\cm,staffsize=16]
+@{pitches-headword.ly@}
@end example
-If you want to use \layout@{@} or define variables, use
+@item
+LSR snippets are linked with:
@example
-@@lilypond[verbatim,quote]
+@@lilypondfile[verbatim,lilyquote,ragged-right,texidoc,doctitle]
+@{filename.ly@}
@end example
-In rare cases, other options may be used (or omitted), but ask first.
+@item
+Use two spaces for indentation in lilypond examples (no tabs).
@item
-Inspirational headwords are produced with
+All engravers should have double-quotes around them:
@example
-@@lilypondfile[quote,ragged-right,line-width=16\cm,staffsize=16]
-@{pitches-headword.ly@}
+\consists "Spans_arpeggio_engraver"
@end example
+LilyPond does not strictly require this, but it is a useful
+convention to follow.
+
+@item
+All context or layout object strings should be prefaced with @code{#}.
+Again, LilyPond does not strictly require this, but it is helpful
+to get users accustomed to this scheme construct, i.e. @code{\set
+Staff.instrumentName = #"cello"}
+
@item
-LSR snippets are linked with
+Try to avoid using @code{#'} or @code{#`} within when describing
+context or layout properties outside of an @code{@@example} or @code{@@lilypond}, unless
+the description explicitly requires it.
+
+i.e. @qq{...setting the @code{transparent} property leaves the object where it
+is, but makes it invisible.}
+
+@item
+If possible, only write one bar per line.
+
+@item
+If you only have one bar per line, omit bar checks. If you
+must put more than one bar per line (not recommended), then include bar
+checks.
+@item
+Tweaks should, if possible, also occur on their own line.
@example
-@@lilypondfile[verbatim,lilyquote,ragged-right,texidoc,doctitle]
-@{filename.ly@}
+not: \override TextScript #'padding = #3 c1^"hi"
+but instead: \override TextScript #'padding = #3
+ c1^"hi"
@end example
@noindent
@item
Avoid long stretches of input code. Nobody is going to read
-them in print. Create small examples. However, this does not mean
+them in print. Create small examples. However, this does not mean
it has be minimal.
@item
the line(s) to which they refer.
@item
-Add extra spaces around @{ @} marks; ie
+For clarity, always use @{ @} marks even if they are not technically
+required; i.e.
@example
-not: \chordmode @{c e g@}
+not:
+
+\context Voice \repeat unfold 2 \relative c' @{
+ c2 d
+@}
+
+but instead:
+
+\context Voice @{
+ \repeat unfold 2 @{
+ \relative c' @{
+ c2 d
+ @}
+ @}
+@}
+@end example
+
+@item
+Add a space around @{ @} marks; i.e.
+
+@example
+not: \chordmode@{c e g@}
but instead: \chordmode @{ c e g @}
@end example
+@item
+Use @{ @} marks for additional @code{\markup} format commands; i.e.
+
+@example
+not: c^\markup \tiny\sharp
+but instead: c^\markup @{ \tiny \sharp @}
+@end example
+
+@item
+Remove any space around @code{<} @code{>} marks; i.e.
+
+@example
+not: < c e g > 4
+but instead: <c e g>4
+@end example
+
+@item
+Beam, slur and tie marks should begin immediately after the first
+note with beam and phrase marks ending immediately after the last.
+
+@example
+a8\( ais16[ b cis( d] b) cis4~ b' cis,\)
+@end example
+
@item
If you want to work on an example outside of the manual (for
easier/faster processing), use this header:
\paper @{
indent = 0\mm
line-width = 160\mm - 2.0 * 0.4\in
- ragged-right = ##t
- force-assignment = #""
line-width = #(- line-width (* mm 3.000000))
@}
@end example
You may not change any of these values. If you are making an
-example demonstrating special \paper@{@} values, contact the
+example demonstrating special @code{\paper@{@}} values, contact the
Documentation Editor.
@end itemize
@subsection Text formatting
@itemize
-
@item
Lines should be less than 72 characters long. (We personally
recommend writing with 66-char lines, but do not bother modifying
-existing material). However, see the note below regarding line
-lengths within @code{@@example} blocks.
-
-@item
-Individual lines within an @code{@@example} block should not
-exceed 74 characters; otherwise they will run into the margin in
-the pdf output, and may get clipped. If an @code{@@example} block
-is part of an @code{@@item} within an @code{@@itemize} or
-@code{@@enumerate} block, each line of the @code{@@example} should
-not exceed 70 columns---each additional level of @code{@@itemize}
-or @code{@@enumerate} shortens the line by about 4 columns.
-
-For command line examples, if possible, use a trailing backslash
-to break up a single line, indenting the next line with 2 spaces.
-If this isn't feasible, use @code{@@smallexample ...
-@@end@tie{}smallexample} instead, which uses a smaller fontsize.
-Use @code{@@example} whenever possible, but if needed,
-@code{@@smallexample} can fit up to 96 characters per line before
-running into the pdf margin. Each additional level of
-@code{@@itemize} or @code{@@enumerate} shortens a
-@code{@@smallexample} line by about 5 columns.
+existing material). Also see the recommendations for fixed-width
+fonts in the @ref{Syntax survey}.
@item
Do not use tabs.
through the code}. If you really want to refer to a context, use
@code{@@code@{@}} in the main text and @code{@@rinternals@{@}} in
the @code{@@seealso}.
+@end itemize
-@item
-Variables or numbers which consist of a single character (probably
-followed by a punctuation mark) should be tied properly, either to
-the previous or the next word. Example:
-@example
-The variable@@tie@{@}@@var@{a@} ...
-@end example
+@node Syntax survey
+@subsection Syntax survey
-@item
-To get consistent indentation in the DVI output it is better to
-avoid the @code{@@verbatim} environment. Use the @code{@@example}
-environment instead if possible, but without extraneous
-indentation. For example, this
-@example
-@@example
- foo @{
- bar
- @}
-@@end example
-@end example
+@menu
+* Comments::
+* Cross references::
+* External links::
+* Fixed-width font::
+* Indexing::
+* Lists::
+* Special characters::
+* Miscellany::
+@end menu
-@noindent
-should be replaced with
-@example
-@@example
-foo @{
- bar
-@}
-@@end example
-@end example
+@node Comments
+@unnumberedsubsubsec Comments
-@noindent
-where @q{@code{@@example}} starts the line (without leading
-spaces).
+@itemize
+@item
+@code{@@c @dots{}} --- single line comment. @samp{@@c NOTE:} is a
+comment which should remain in the final version. (gp only
+command ;)
@item
-Do not compress the input vertically; that is, do not use
+@code{@@ignore} --- multi-line comment:
@example
-Beginning of logical unit
-@@example
-...
-@@end example
-continuation of logical unit
+@@ignore
+@dots{}
+@@end ignore
@end example
+@end itemize
-@noindent
-but instead do
-@example
-Beginning of logical unit
+@node Cross references
+@unnumberedsubsubsec Cross references
-@@example
-...
-@@end example
+Enter the exact @code{@@node} name of the target reference between
+the brackets (eg.@tie{}@w{@samp{@@ref@{Syntax survey@}}}). Do not
+split a cross-reference across two lines -- this causes the
+cross-reference to be rendered incorrectly in html documents.
-@@noindent
-continuation of logical unit
-@end example
+@itemize
+@item
+@code{@@ref@{@dots{}@}} --- link within current manual.
-This makes it easier to remember the @q{@code{@@noindent}}. Only
-use @code{@@noindent} if the material is discussing the same
-material; new material should simply begin without anything
-special on the line above it.
+@item
+@code{@@rchanges@{@dots{}@}} --- link to Changes.
@item
-in @code{@@itemize} and @code{@@enumerate} blocks, use
-@code{@@item} on a separate line like this:
+@code{@@rcontrib@{@dots{}@}} --- link to Contributor's Guide.
-@example
-@@itemize
-@@item
-Foo
+@item
+@code{@@ressay@{@dots{}@}} --- link to Engraving Essay.
-@@item
-Bar
-@end example
+@item
+@code{@@rextend@{@dots{}@}} --- link to Extending LilyPond.
-Do not use @code{@@itemize@tie{}@@bullet}.
+@item
+@code{@@rglos@{@dots{}@}} --- link to the Music Glossary.
@item
-To get LilyPond version, use @code{@@version@{@}} (this does not
-work inside LilyPond snippets). If you write
-@code{"@@version@{@}"} (enclosed with quotes), or generally if
-@code{@@version@{@}} is not followed by a space, there will be an
-ugly line break in PDF output unless you enclose it with
+@code{@@rinternals@{@dots{}@}} --- link to the Internals Reference.
-@example
-@@w@{ ... @}
+@item
+@code{@@rlearning@{@dots{}@}} --- link to Learning Manual.
- e.g.
+@item
+@code{@@rlsr@{@dots{}@}} --- link to a Snippet section.
-@@w@{"@@version@{@}"@}
-@end example
+@item
+@code{@@rprogram@{@dots{}@}} --- link to Application Usage.
+@item
+@code{@@ruser@{@dots{}@}} --- link to Notation Reference.
+
+@item
+@code{@@rweb@{@dots{}@}} --- link to General Information.
@end itemize
-@node Syntax survey
-@subsection Syntax survey
+@node External links
+@unnumberedsubsubsec External links
@itemize
@item
-@code{@@bs} --- Generates a backslash inside @code{@@warning}.
-Any @q{@bs{}} used inside @code{@@warning} (and @code{@@q} or
-@code{@@qq}) must be written as @q{@code{@@bs@{@}}} (texinfo would
-also allow @q{@bs{}@bs{}}, but this breaks with PDF output).
+@code{@@email@{@dots{}@}} --- create a @code{mailto:} E-mail link.
@item
-@code{@@c} --- single line comments. @qq{@code{@@c NOTE:}} is a
-comment which should remain in the final version. (gp only
-command ;)
+@code{@@uref@{@var{URL}[, @var{link text}]@}} --- link to an
+external url. Use within an @code{@@example ... @@end example}.
-@item
-@code{@@cindex} --- General index. Please add as many as you can.
-Don't capitalize the first word.
+@example
+@@example
+@@uref@{URL [, link text ]@}
+@@end example
+@end example
+@end itemize
-@item
-@code{@@code@{@}} --- typeset in a tt-font. Use for actual
-LilyPond code or property/context names. If the name contains a
-space, wrap the entire thing inside @code{@@w@{@@code@{ @}@}}.
-@item
-@code{@@example ... @@end example} --- example text that should be
-set as a blockquote. Any @code{@{@tie{}@}} must be escaped with
-@code{@@@{@tie{}@@@}}.
+@node Fixed-width font
+@unnumberedsubsubsec Fixed-width font
+@itemize
@item
-@code{@@funindex} --- is for a \lilycommand.
+@code{@@code@{@dots{}@}}, @code{@@samp@{@dots{}@}} ---
+
+Use the @code{@@code@{@dots{}@}} command when referring to
+individual language-specific tokens (keywords, commands,
+engravers, scheme symbols, etc.) in the text. Ideally, a single
+@code{@@code@{@dots{}@}} block should fit within one line in the
+PDF output.
+
+Use the @code{@@samp@{@dots{}@}} command when you have a short
+example of user input, unless it constitutes an entire
+@code{@@item} by itself, in which case @code{@@code@{@dots{}@}} is
+preferable. Otherwise, both should only be used when part of a
+larger sentence within a paragraph or @code{@@item}. Do not use
+@code{@@code@{@dots{}@}} or @code{@@samp@{@dots{}@}} inside an
+@code{@@example} block, and do not use either as a free-standing
+paragraph; use @code{@@example} instead.
+
+A single unindented line in the PDF has space for about 79
+fixed-width characters (76 if indented). Within an @code{@@item}
+there is space for about 75 fixed-width characters. Each
+additional level of @code{@@itemize} or @code{@@enumerate}
+shortens the line by about 4 columns.
+
+However, even short blocks of @code{@@code@{@dots{}@}} and
+@code{@@samp@{@dots{}@}} can run into the margin if the Texinfo
+line-breaking algorithm gets confused. Additionally, blocks that
+are longer than this may in fact print nicely; it all depends
+where the line breaks end up. If you compile the docs yourself,
+check the PDF output to make sure the line breaks are
+satisfactory.
+
+The Texinfo setting @code{@@allowcodebreaks} is set to
+@code{false} in the manuals, so lines within
+@code{@@code@{@dots{}@}} or @code{@@samp@{@dots{}@}} blocks will
+only break at spaces, not at hyphens or underscores. If the block
+contains spaces, use @code{@@w@{@@code@{@dots{}@}@}} or
+@code{@@w@{@@samp@{@dots{}@}@}} to prevent unexpected line breaks.
+
+The Texinfo settings @code{txicodequoteundirected} and
+@code{txicodequotebacktick} are both set in the manuals, so
+backticks (@code{`}) and apostrophes (@code{'}) placed within
+blocks of @code{@@code}, @code{@@example}, or @code{@@verbatim}
+are not converted to left- and right-angled quotes
+(@code{@quoteleft{} @quoteright{}}) as they normally are within
+the text, so the apostrophes in
+@q{@w{@code{@@w@{@@code@{@bs{}relative c''@}@}}}} will display
+correctly. However, these settings do not affect the PDF output
+for anything within a @code{@@samp} block (even if it includes a
+nested @code{@@code} block), so entering
+@q{@code{@@w@{@@samp@{@bs{}relative c''@}@}}} wrongly produces
+@q{@w{@code{@bs{}relative c@quoteright{}@quoteright{}}}} in PDF.
+Consequently, if you want to use a @code{@@samp@{@dots{}@}} block
+which contains backticks or apostrophes, you should instead use
+@q{@code{@@q@{@@code@{@dots{}@}@}}} (or
+@q{@code{@@q@{@@w@{@@code@{@dots{}@}@}@}}} if the block also
+contains spaces). Note that backslashes within
+@code{@@q@{@dots{}@}} blocks must be entered as @samp{@@bs@{@}},
+so the example above would be coded as
+@q{@code{@@q@{@@w@{@@code@{@@bs@{@}relative c''@}@}@}}}.
+
+@item
+@code{@@command@{@dots{}@}} --- Use when referring to command-line
+commands within the text (eg. @samp{@@command@{convert-ly@}}). Do
+not use inside an @code{@@example} block.
+
+@item
+@code{@@example} --- Use for examples of program code. Do not add
+extraneous indentation (i.e. don't start every line with
+whitespace). Use the following layout (notice the use of blank
+lines). Omit the @code{@@noindent} if the text following the
+example starts a new paragraph:
-@item
-@code{@@ignore ... @@end ignore} --- multi-line comment
+@example
+@var{@dots{}text leading into the example@dots{}}
-@item
-@code{@@itemize @@item A @@item B ... @@end itemize} --- for
-bulleted lists. Do not compress vertically like this.
+@@example
+@dots{}
+@@end example
-@item
-@code{@@notation@{@}} --- refers to pieces of notation, e.g.
-@qq{@code{@@notation@{clef}.@}}. Also use for specific lyrics
-(@qq{the @code{@@notation@{}A@tie{}-@tie{}men@} is centered}).
-Only use once per subsection per term.
+@@noindent
+@var{continuation of the text@dots{}}
+@end example
-@item
-@code{@@q@{@}} --- Single quotes. Used for @q{vague} terms.
+Individual lines within an @code{@@example} block should not
+exceed 74 characters; otherwise they will run into the margin in
+the PDF output, and may get clipped. If an @code{@@example} block
+is part of an @code{@@item}, individual lines in the
+@code{@@example} block should not exceed 70 columns. Each
+additional level of @code{@@itemize} or @code{@@enumerate}
+shortens the line by about 4 columns.
+
+For long command line examples, if possible, use a trailing
+backslash to break up a single line, indenting the next line with
+2 spaces. If this isn't feasible, use @samp{@@smallexample
+@dots{} @@end@tie{}smallexample} instead, which uses a smaller
+fontsize. Use @code{@@example} whenever possible, but if needed,
+@code{@@smallexample} can fit up to 90 characters per line before
+running into the PDF margin. Each additional level of
+@code{@@itemize} or @code{@@enumerate} shortens a
+@code{@@smallexample} line by about 5 columns.
@item
-@code{@@qq@{@}} --- Double quotes. Used for actual quotes (@qq{he
-said}) or for introducing special input modes.
+@code{@@file@{@dots{}@}} --- Use when referring to filenames and
+directories in the text. Do not use inside an @code{@@example}
+block.
@item
-@code{@@rchanges@{@}} --- link to Changes.
+@code{@@option@{@dots{}@}} --- Use when referring to command-line
+options in the text (eg. @samp{@@option@{--format@}}). Do not use
+inside an @code{@@example} block.
@item
-@code{@@rcontrib@{@}} --- link to Contributor's Guide.
+@code{@@verbatim} --- Prints the block exactly as it appears in
+the source file (including whitespace, etc.). For program code
+examples, use @code{@@example} instead. @code{@@verbatim} uses
+the same format as @code{@@example}.
+
+Individual lines within an @code{@@verbatim} block should not
+exceed 74 characters; otherwise they will run into the margin in
+the PDF output, and may get clipped. If an @code{@@verbatim}
+block is part of an @code{@@item}, individual lines in the
+@code{@@verbatim} block should not exceed 70 columns. Each
+additional level of @code{@@itemize} or @code{@@enumerate}
+shortens the line by about 4 columns.
+@end itemize
-@item
-@code{@@ref@{@}} --- link within current manual (type the exact
-node name inside the @code{@{@}}).
+@node Indexing
+@unnumberedsubsubsec Indexing
+
+@itemize
@item
-@code{@@ressay@{@}} --- link to Engraving Essay.
+@code{@@cindex @dots{}} --- General index. Please add as many as you can.
+Don't capitalize the first word.
@item
-@code{@@rextend@{@}} --- link to Extending LilyPond.
+@code{@@funindex @dots{}} --- is for a \lilycommand.
+@end itemize
+
+
+@node Lists
+@unnumberedsubsubsec Lists
+@itemize
@item
-@code{@@rglos@{@}} --- link to the Music Glossary.
+@code{@@enumerate} --- Create an ordered list (with numbers).
+Always put @samp{@@item} on its own line. As an exception, if all
+the items in the list are short enough to fit on single lines, placing
+them on the @samp{@@item} lines is also permissible. @samp{@@item}
+and @samp{@@end@tie{}enumerate} should always be preceded by a blank
+line.
+
+@example
+@@enumerate
+
+@@item
+A long multi-line item like this one must begin
+on a line of its own and all the other items in
+the list must do so too.
+
+@@item
+Even short ones
+
+@@end enumerate
+@end example
+
+@example
+@@enumerate
+
+@@item Short item
+
+@@item Short item
+
+@@end enumerate
+@end example
@item
-@code{@@rinternals@{@}} --- link to the Internals Reference.
+@code{@@itemize} --- Create an unordered list (with bullets). Use
+the same format as @code{@@enumerate}. Do not use
+@samp{@@itemize@tie{}@@bullet}.
+@end itemize
+
+@node Special characters
+@unnumberedsubsubsec Special characters
+
+@itemize
@item
-@code{@@rlearning@{@}} --- link to Learning Manual.
+@code{--}, @code{---} --- Create an en dash (--) or an em dash
+(---) in the text. To print two or three literal hyphens in a
+row, wrap one of them in a @code{@@w@{@dots{}@}} (eg.
+@samp{-@@w@{-@}-}).
@item
-@code{@@rlsr@{@}} --- link to a Snippet section.
+@code{@@@@}, @code{@@@{}, @code{@@@}} --- Create an at-sign (@@),
+a left curly bracket (@{), or a right curly bracket (@}).
@item
-@code{@@rprogram@{@}} --- link to Application Usage.
+@code{@@bs@{@}} --- Create a backslash within a
+@code{@@q@{@dots{}@}}, @code{@@qq@{@dots{}@}}, or
+@code{@@warning@{@dots{}@}} block. This is a custom LilyPond
+macro, not a builtin @@-command in Texinfo. Texinfo would also
+allow @samp{\\}, but this breaks the PDF output.
@item
-@code{@@ruser@{@}} --- link to Notation Reference.
+@code{@@tie@{@}} --- Create a @emph{variable-width} non-breaking
+space in the text (use @w{@samp{@@w@{ @}}} for a single
+@emph{fixed-width} non-breaking space). Variables or numbers
+which consist of a single character (probably followed by a
+punctuation mark) should be tied properly, either to the previous
+or the next word. Example: @samp{The letter@@tie@{@}@@q@{I@} is
+skipped}
+@end itemize
+
+
+@node Miscellany
+@unnumberedsubsubsec Miscellany
+@itemize
@item
-@code{@@rweb@{@}} --- link to General Informaion.
+@code{@@notation@{@dots{}@}} --- refers to pieces of notation, e.g.
+@samp{@@notation@{clef@}}. Also use for specific lyrics
+(@samp{the @@notation@{A@tie{}-@tie{}men@} is centered}).
+Only use once per subsection per term.
@item
-@code{@@tie@{@}} --- Variables or numbers which consist of a
-single character (probably followed by a punctuation mark) should
-be tied properly, either to the previous or the next word.
-Example: @q{@code{The letter@@tie@{@}@@q@{I@} is skipped}}
+@code{@@q@{@dots{}@}} --- Single quotes. Used for
+@quoteleft{}vague@quoteright{} terms. To get a backslash
+(\), you must use @samp{@@bs@{@}}.
@item
-@code{@@uref@{@}} --- link to an external url.
+@code{@@qq@{@dots{}@}} --- Double quotes. Used for actual quotes
+(@qq{he said}) or for introducing special input modes. To get a
+backslash (\), you must use @samp{@@bs@{@}}.
@item
-@code{@@var} --- Use for variables.
+@code{@@var@{@dots{}@}} --- Use for metasyntactic variables (such
+as @code{@var{foo}}, @code{@var{bar}}, @code{@var{arg1}}, etc.).
+In most cases, when the @code{@@var@{@dots{}@}} command appears in
+the text (and not in an @code{@@example} block) it should be
+wrapped with an appropriate texinfo code-highlighting command
+(such as @code{@@code}, @code{@@samp}, @code{@@file},
+@code{@@command}, etc.). For example:
+@samp{@@code@{@@var@{foo@}@}},
+@samp{@@file@{@@var@{myfile.ly@}@}},
+@w{@samp{@@samp@{git checkout @@var@{branch@}@}}}, etc. This
+improves readability in the PDF and HTML output.
@item
@code{@@version@{@}} --- Return the current LilyPond version
-string.
+string. Use @samp{@@w@{@@version@{@}@}} if it's at the end of a
+line (to prevent an ugly line break in PDF); use
+@samp{@@w@{"@@version@{@}"@}} if you need it in quotes.
@item
-@code{@@warning@{@}} --- produces a @qq{Note:@tie{}} box. Use for
-important messages.
+@code{@@w@{@dots{}@}} --- Do not allow any line breaks.
+@item
+@code{@@warning@{@dots{}@}} --- produces a @qq{Note:@tie{}} box.
+Use for important messages. To get a backslash (\), you must use
+@samp{@@bs@{@}}.
@end itemize
-
@node Other text concerns
@subsection Other text concerns
@itemize
-
@item
References must occur at the end of a sentence, for more
-information see @@ref@{the texinfo manual@}. Ideally this should
-also be the final sentence of a paragraph, but this is not
-required. Any link in a doc section must be duplicated in the
-@@seealso section at the bottom.
+information see the
+@uref{http://www.gnu.org/software/texinfo/manual/texinfo/,texinfo
+manual}. Ideally this should also be the final sentence of a
+paragraph, but this is not required. Any link in a doc section
+must be duplicated in the @code{@@seealso} section at the bottom.
@item
Introducing examples must be done with
@example
-. (ie finish the previous sentence/paragaph)
-: (ie `in this example:')
-, (ie `may add foo with the blah construct,')
+. (i.e. finish the previous sentence/paragraph)
+: (i.e. `in this example:')
+, (i.e. `may add foo with the blah construct,')
@end example
The old @qq{sentence runs directly into the example} method is not
Colon usage
@enumerate
-
@item
To introduce lists
@item
-When beginning a quote: "So, he said,...".
+When beginning a quote: @qq{So, he said,...}.
This usage is rarer. Americans often just use a comma.
@item
When adding a defining example at the end of a sentence.
-
@end enumerate
@item
Non-ASCII characters which are in utf-8 should be directly used;
-this is, don't say @q{Ba@@ss@{@}tuba} but @q{Baßtuba}. This ensures
-that all such characters appear in all output formats.
-
+this is, don't say @samp{Ba@@ss@{@}tuba} but @samp{Baßtuba}. This
+ensures that all such characters appear in all output formats.
@end itemize
-
-
@node Documentation policy
@section Documentation policy
see @@ref@{Controlling direction and placement@}.
Most tweaks should be added to LSR and not placed directly in the
-.itely file. In some cases, tweaks may be placed in the main
+@file{.itely} file. In some cases, tweaks may be placed in the main
text, but ask about this first.
Finally, you should assume that users know what the notation
Application Usage:
@@rprogram@{blah@}.
+Essay on automated music engraving:
+@@ressay@{yadda@}.
+
Extending LilyPond:
@@rextend@{frob@}.
@file{ly/*-init.ly}
@item
-Do not include any real info in second-level sections (ie 1.1
+Do not include any real info in second-level sections (i.e. 1.1
Pitches). A first-level section may have introductory material,
but other than that all material goes into third-level sections
-(ie 1.1.1 Writing Pitches).
+(i.e. 1.1.1 Writing Pitches).
+
+@item
+The @@knownissues should not discuss any issues that are in the
+tracker, unless the issue is Priority-Postponed. The goal is to
+discuss any overall architecture or syntax decisions which may be
+interpreted as bugs. Normal bugs should not be discussed here,
+because we have so many bugs that it would be a huge task to keep
+the @@knownissues current and accurate all the time.
@end itemize
@end example
@noindent
-do not bother with the @@code@{@} (they are added automatically).
+Do not bother with the @@code@{@} (they are added automatically).
These items are added to both the command index and the unified
-index.
+index. Both index commands should go in front of the actual material.
-Both index commands should go in front of the actual material.
-
-@@cindex entries should not be capitalized, ie
+@item
+@@cindex entries should not be capitalized, i.e.
@example
@@cindex time signature
@end example
@noindent
-is preferred instead of @qq{Time signature}, Only use capital
-letters for musical terms which demand them, like D.S. al Fine.
+is preferred instead of @qq{Time signature}. Only use capital
+letters for musical terms which demand them, e.g.
+@qq{D.S. al Fine}.
-For scheme functions, only include the final part, i.e.,
+@item
+For scheme function index entries, only include the final part, i.e.
@example
@@funindex modern-voice-cautionary
@end example
@item
-Preferred terms:
+Use American spelling. LilyPond's internal property
+names use this convention.
+
+@item
+Here is a list of preferred terms to be used:
@itemize
+@item
+@emph{Simultaneous} NOT concurrent.
@item
-In general, use the American spellings. The internal lilypond
-property names use this spelling.
+@emph{Measure}: the unit of music.
@item
-List of specific terms:
+@emph{Bar line}: the symbol delimiting a measure NOT barline.
-@example
-canceled
-simultaneous NOT concurrent
-measure: the unit of music
-bar line: the symbol delimiting a measure NOT barline
-note head NOT notehead
-chord construct NOT chord (when referring to <>)
-@end example
+@item
+@emph{Note head} NOT notehead.
+
+@item
+@emph{Chord construct} NOT just chord (when referring to < ... >)
+
+@item
+@emph{Staff} NOT stave.
+
+@item
+@emph{Staves} NOT Staffs:
+Phrases such as
+@q{multiple @@internalsref@{Staff@}s}
+should be rephrased to
+@q{multiple @@internalsref@{Staff@} contexts}.
@end itemize
+
@end itemize
@item
move LSR-worthy material into LSR. Add the snippet, delete the
-material from the .itely file, and add a @@lilypondfile command.
+material from the @file{.itely} file, and add a @@lilypondfile command.
@item
check the examples and descriptions. Do they still work?
In general, any \set or \override commands should go in the
@qq{select snippets} section, which means that they should go in
-LSR and not the .itely file. For some cases, the command
+LSR and not the @file{.itely} file. For some cases, the command
obviously belongs in the @qq{main text} (i.e. not inside
@@predefined or @@seealso or whatever) -- instrument names are a
good example of this.
@node Scripts to ease doc work
@section Scripts to ease doc work
-@subheading Stripping whitespace
+@subheading Building only one section of the documentation
-@c TODO: should this be documented elsewhere? It's useful for
-@c more than just docs.
-To remove extra whitespace from the ends of lines, run
+In order to save build time, a script is available to build only
+one section of the documentation in English with a default html
+appearance.
+
+The script is available as:
@example
-scripts/auxiliar/strip-whitespace.py Documentation/FILENAME
+scripts/auxiliar/doc-section.sh
@end example
+This script will require customization for your site if your
+LilyPond git repository is anyplace but @code{$HOME/lilypond}.
-@subheading Sectioning commands
+Assuming that no customization is required, you can setup the
+single section build with:
-@warning{These commands add whitespace.}
+@example
+mkdir $HOME/lilypond/tempdocs
+cp $HOME/lilypond/Documentation/out/version.itexi $HOME/lilypond/tempdocs
+@end example
-The emacs @code{M-x texinfo-all-menus-update} command will
-regenerate @@menu blocks. This can also be run with this
-command-line script:
+You can then build a section of the documentation with:
@example
-#!/bin/sh
-emacs $1 -batch -f texinfo-all-menus-update -f save-buffer
+scripts/auxiliar/doc-section.sh MANUAL SECTION
@end example
@noindent
-(save the above as something like @command{texinfo-menus.sh}, make
-it executable, then run @command{texinfo-menus.sh foo.itely})
+where @code{SECTION} is the name of the file containing the section
+to be built, and @code{MANUAL} is replaced by the name of the directory
+containing the section. So, for example, to build section 1.1 of the
+Notation Reference, use the command:
+@example
+scripts/auxiliar/doc-section.sh notation pitches
+@end example
-@subheading Updating doc with @command{convert-ly}
-
-cd into @file{Documentation/} and run
+This script will not work for building sections of the
+Contributors' guide. For building sections of the Contributors'
+Guide, use:
@example
-find . -name '*.itely' | xargs convert-ly -e
+scripts/auxiliar/cg-section.sh SECTION
@end example
@noindent
-This also updates translated documentation.
+where @code{SECTION} is the name of the file containing the sections
+to be built. For example, to build section 4 of the Contributors' guide,
+use:
+
+@example
+scripts/auxiliar/cg-section.sh doc-work
+@end example
+
+Like @code{doc-section.sh}, @code{cg-section.sh} may need to be customized
+for your installation.
+
+@subheading Stripping whitespace and generating menus
+
+@warning{This script assumes that the file conforms to our doc
+policy; a few files still need work in this regard.}
+
+To automatically regenerate @code{@@menu} portions and strip
+whitespace, use:
+
+@example
+scripts/auxiliar/node-menuify.py @var{FILENAME}
+@end example
+
+
+@subheading Stripping whitespace only
+
+@c TODO: should this be documented elsewhere? It's useful for
+@c more than just docs.
+To remove extra whitespace from the ends of lines, run
+
+@example
+scripts/auxiliar/strip-whitespace.py Documentation/FILENAME
+@end example
+
+
+@subheading Updating doc with @command{convert-ly}
+Don't. This should be done by programmers when they add new
+features. If you notice that it hasn't been done, complain to
+@code{lilypond-devel}.
@node Docstrings in scheme
The mailing list @code{translations@@lilynet.net} is dedicated to
LilyPond web site and documentation translation; on this list, you will
-get support from the Translations Meister and experimented translators,
-and we regularly discuss translations issues common to all languagues.
+get support from the Translations Meister and experienced translators,
+and we regularly discuss translation issues common to all languages.
All people interested in LilyPond translations are invited to subscribe
to this list regardless of the amount of their contribution, by sending
an email to @code{translations-request@@lilynet.net} with subject
-@code{subscribe} and an empty message body. Unless mentioned explicitly
+@code{subscribe} and an empty message body. Unless mentioned explicitly,
or except if a translations coordinator contacts you privately, you
-should send questions, remarks, patches to this list
-@code{translations@@lilynet.net}; especially note that the traffic is so
-high on English-speaking list @code{lilypond-user@@gnu.org} that it may
-take months before your request or contribution is handled if you send a
-email to these lists.
+should send questions, remarks and patches to the list
+@code{translations@@lilynet.net}. Please note that traffic is high
+on the English-speaking list @code{lilypond-user@@gnu.org}, so it may
+take some time before your request or contribution is handled.
@menu
* Getting started with documentation translation::
translate the documentation. However, if you have enough time and
motivation and a suitable system, it can be very useful to build at
least the documentation so that you can check the output yourself and
-more quickly; if you are interested, see @ref{Compiling from source}.
+more quickly; if you are interested, see @ref{Compiling}.
+
+Before undertaking any large translation work, contributors are
+encouraged to contact the @ref{Meisters, Translation Meister}.
@node Which documentation can be translated
@@@var{section_commmand} @@translationof} trio mentioned above) in the
expected source file and define all its parent nodes; for each node you
have defined this way but have not translated, insert a line that
-contains @code{@@untranslated}. That is, you should end up
+contains @code{@@untranslated}. That is, you should end up
for each untranslated node with something like
@example
original text; for instance, in the translation of the web site section
Community, you may take this into account depending on what you know the
community in your language is willing to support, which is possible only
-if you personnally assume this support, or there exists a public forum
+if you personally assume this support, or there exists a public forum
or mailing list listed in Community for LilyPond in your language:
@itemize
comments i.e. lines starting with @q{@code{@@c}}.
Finally, press in Emacs @key{C-c C-u C-a} to update or generate
-menus. This process should be made easier in the future, when the helper
+menus. This process should be made easier in the future, when the helper
script @command{texi-langutils.py} and the makefile target are updated.
Some pieces of text manipulated by build scripts that appear in the
in the source, open @file{Documentation/snippets/@var{filename}.ly},
translate the @code{texidoc} header field it contains, enclose it with
@code{texidoc@var{MY-LANGUAGE} = "} and @code{"}, and write it into
-@file{Documentation/@var{MY-LANGUAGE}/texidocs/@var{filename}.texidoc}.
-Additionnally, you may translate the snippet's title in @code{doctitle}
+@file{Documentation/@var{MY-LANGUAGE}/texidocs/@/@var{filename}.texidoc}.
+Additionally, you may translate the snippet's title in @code{doctitle}
header field, in case @code{doctitle} is a fragment option used in
@code{@@lilypondfile}; you can do this exactly the same way as
@code{texidoc}. For instance,
-@file{Documentation/@var{MY-LANGUAGE}/texidocs/@var{filename}.texidoc}
+@file{Documentation/@var{MY-LANGUAGE}/texidocs/@/@var{filename}.texidoc}
may contain
@example
@seeCommittishesUpdate
-@warning{translation status generation is currently broken, so
-translation status pages have been removed; it will be regenerated again
-as soon as possible, in Texinfo format.}
-
Global state of the translation is recorded in
-@file{Documentation/translations.html.in}, which is used to generate
+@file{Documentation/translations.itexi}, which is used to generate
Translations status page. To update that page, do from
@file{Documentation/}
@seealso
@ref{Maintaining without updating translations}.
-
@node Updating documentation translation
@unnumberedsubsubsec Updating documentation translation
make CHECKED_FILES=@var{MY_LANGUAGE/@var{manual}/foo.itely} update-translation
@end example
-For each file to be udpated, @code{update-translation} will open your
+For each file to be updated, @code{update-translation} will open your
text editor with this file and a diff of the file in English; if the
diff cannot be generated or is bigger than the file in English itself,
the full file in English will be opened instead.
@seealso
@ref{LSR work}.
-
@node Translations management policies
@subsection Translations management policies
@item Update macros.itexi.
For each obsolete macro definition, if it is possible to update macro
usage in documentation with an automatic text or regexp substitution,
-do it and delete the macro definition from macros.itexi; otherwise,
+do it and delete the macro definition from @file{macros.itexi}; otherwise,
mark this macro definition as obsolete with a comment, and keep it in
-macros.itexi until the documentation translation has been updated and
+@file{macros.itexi} until the documentation translation has been updated and
no longer uses this macro.
@item Update @file{*.tely} files completely with
-@command{make check-translation} -- you may want to redirect ouptput
+@command{make check-translation} -- you may want to redirect output
to a file because of overwhelming output, or call check-translation.py
on individual files, see @ref{Check state of translation}.
@item Update sections finished in the English documentation; check
sections status at
+@smallexample
@uref{http://lilypondwiki.tuxfamily.org/index.php?title=Documentation_coordination}.
+@end smallexample
@item Update documentation PO. It is recommended not to update
strings which come from documentation that is currently deeply revised
@end example
@noindent
-This step requires a sucessful documentation build (with @command{make
+This step requires a successful documentation build (with @command{make
doc}). Some cross-references are broken because they point to a node
that exists in the documentation in English, which has not been added
to the translation; in this case, do not fix the cross-reference but
@item @code{lilypond/translation} Git branch may be merged into
master only if LilyPond (@command{make all}) and documentation
-(@command{make doc}) compile succesfully.
+(@command{make doc}) compile successfully.
@item @code{master} Git branch may be merged into
@code{lilypond/translation} whenever @command{make} and @command{make
-doc} are succesful (in order to ease documentation compilation by
+doc} are successful (in order to ease documentation compilation by
translators), or when significant changes had been made in
documentation in English in master branch.
projects / lilypond.git / blobdiff