@c * Preface:: Preface.
@c * Introduction:: What, Why, How.
+@c * Working on LilyPond projects:: Discusses real-life usage.
@menu
* Introduction:: Begin here.
* Common notation:: A tutorial introduction.
* Fundamental concepts:: Basic concepts required for reading the rest of this manual.
* Tweaking output:: Introduction to modifying output.
-* Working on LilyPond projects:: Discusses real-life usage.
Appendices
@include learning/common-notation.itely
@include learning/fundamental.itely
@include learning/tweaks.itely
-@include learning/working.itely
+@c @include learning/working.itely
@include learning/templates.itely
@include learning/scheme-tutorial.itely
It is essential that the final syllable is separated from the
terminating curly bracket by a space or a newline, or it will be
assumed to be part of the syllable, giving rise to an obscure
-error, see @ref{Apparent error in ../ly/init.ly}.
+error, see @rprogram{Apparent error in ../ly/init.ly}.
Note also the double angle brackets @w{@code{<< ... >>}} around the
whole piece to show that the music and lyrics are to occur at the
@end lilypond
Using variables is also a good way to reduce work if the
-LilyPond input syntax changes (see @ref{Updating old input files}). If
+LilyPond input syntax changes (see @rprogram{Updating old input files}). If
you have a single definition (such as @code{\dolce}) for all your
input files (see @ref{Style sheets}), then if the syntax changes, you
only need to update your single @code{\dolce} definition,