set of source files.
To organize multiple authors working on the documentation, we use a
-Version Control System (VCS) called git, previously discussed in
+Version Control System (VCS) called Git, previously discussed in
@ref{Starting with Git}.
@menu
@emph{selected snippet} in the documentation. It will also appear
automatically in the Snippets lists. See @ref{Introduction to LSR}.
-Snippets that @emph{don't} have the @qq{docs} tage will still be
+Snippets that @emph{don't} have the @qq{docs} tag will still be
searchable and viewable within the LSR, but will be not be included in
the Snippets list or be able to be included as part of the main
documentation.
@item Level 5: @@subsubsubheading
@end itemize
-The first three levels are numbered in html, the last two are not.
-Numbered sections correspond to a single html page in the split html
+The first three levels are numbered in HTML, the last two are not.
+Numbered sections correspond to a single HTML page in the split HTML
documents.
The first four levels always have accompanying nodes so they can be
-referenced and are also included in the ToC in html.
+referenced and are also included in the ToC in HTML.
Most of the manual is written at level 4 under headings created with
with:
@example
-@@lilypond[verbatim,quote,relative=1]
+@@lilypond[verbatim,quote]
@end example
-or
-
-@example
-@@lilypond[verbatim,quote,relative=2]
-@end example
-
-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.
-
-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
+If using @code{\book@{@}} in your example then 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
@code{@@lilypond} parameters.
@example
-not: @@lilypond [verbatim, quote, relative=1]
-but instead: @@lilypond[verbatim,quote,relative=1]
+not: @@lilypond [verbatim, quote, fragment]
+but instead: @@lilypond[verbatim,quote,fragment]
@end example
@item
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.
+cross-reference to be rendered incorrectly in HTML documents.
@itemize
@item
@node Special characters
@unnumberedsubsubsec Special characters
+@warning{In Texinfo, the backslash is an ordinary character, and
+is entered without escaping (e.g.
+@samp{The@tie{}@@code@{@bs{}foo@}@tie{}command}). However, within
+double-quoted Scheme and/or LilyPond strings, backslashes
+(including those ending up in Texinfo markup) need to be escaped
+by doubling them:
+@example
+(define (foo x)
+ "The @@code@{@bs{}@bs{}foo@} command..."
+ ...)
+@end example}
+
@itemize
@item
@code{--}, @code{---} --- Create an en dash (--) or an em dash
cross-references in the generated documentation such as the
Internals Reference; e.g. you can grep scm/ and lily/.
-@c temporary? how long will kainhofer be used? -gp
-Also of interest may be the linkdoc checks on kainhofer.com. Be
-warned that these docs are not completely rebuilt every day, so it
-might not accurately reflect the current state of the docs.
-
-@example
-@uref{http://kainhofer.com/~lilypond/linkdoc/}
-@end example
-
@node General writing
@subsection General writing
@unnumberedsubsubsec Building only one section of the documentation
In order to save build time, a script is available to build only
-one section of the documentation in English with a default html
+one section of the documentation in English with a default HTML
appearance.
-You can build a section of the documentation with:
+If you do not yet have a @file{build/} subdirectory within the LilyPond
+Git tree, you should create this first. You can then build a section of
+the documentation with the following command:
@example
scripts/auxiliar/doc-section.sh MANUAL SECTION
You can then see the generated document for the section at
@example
-tempdocs/pitches/out/pitches.html
+build/tempdocs/pitches/out/pitches.html
@end example
According to
-@uref{http://code.google.com/p/lilypond/issues/detail?id=1236,Lilypond issue 1236},
-the location of the lilypond git tree is taken from @code{$LILYPOND_GIT}
+@uref{http://code.google.com/p/lilypond/issues/detail?id=1236,LilyPond issue 1236},
+the location of the LilyPond Git tree is taken from @code{$LILYPOND_GIT}
if specified, otherwise it is auto-detected.
It is assumed that compilation takes place in the @file{build/}
@code{LILYPOND_TEMPDOCS}.
This script will not work for building sections of the
-Contributors' guide. For building sections of the Contributors'
+Contributors' Guide. For building sections of the Contributors'
Guide, use:
@example
@noindent
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,
+to be built. For example, to build section 4 of the Contributors' Guide,
use:
@example
on bug-lilypond or add an issue in the tracker, then translate back the
reply from developers.
-@item @rweb{Help us}: this page should be translated very freely,
+@item @rcontrib{Help us}: this page should be translated very freely,
and possibly not at all: ask help for contributing to LilyPond for tasks
that LilyPond community in your language is able and going to handle.
@end itemize
projects / lilypond.git / blobdiff