@c -*- coding: utf-8; mode: texinfo; -*-
+@c This file is part of lilypond.tely
+@ignore
+ Translation of GIT committish: FILL-IN-HEAD-COMMITTISH
+
+ When revising a translation, copy the HEAD committish of the
+ version that you are working on. See TRANSLATION for details.
+@end ignore
+
@node Working on LilyPond projects
@chapter Working on LilyPond projects
-This section explains a how to solve or avoid certain common
+This section explains how to solve or avoid certain common
problems. If you have programming experience, many of these
tips may seem obvious, but it is still advisable to read
this chapter.
* Style sheets::
* Updating old files::
* Troubleshooting (taking it all apart)::
+* Minimal examples::
@end menu
@item @strong{Include checks}: @ref{Bar check} and @ref{Octave check}. If
you
include checks every so often, then if you make a mistake, you can pinpoint
-it quicker. How often is ``every so often''? It depends on the complexity
+it quicker. How often is @q{every so often}? It depends on the complexity
of the music. For very simple music, perhaps just once or twice. For
very complex music, perhaps every bar.
either in the music
itself or in the output you desire, it's often good to write only one bar
per line. Saving screen space by cramming eight bars per line just isn't
-worth it if you have to `debug' your files.
+worth it if you have to @q{debug} your files.
@item @strong{Comment your files}. Use either bar numbers (every so often)
or
-references to musical themes (``second theme in violins,'' ``fourth
-variation'', etc). You may not need comments when you're writing the piece
+references to musical themes (@q{second theme in violins,} @q{fourth
+variation,} etc.). You may not need comments when you're writing the piece
for the first time, but if you want to go back to change something two or
three years later, or if you pass the source over to a friend, it will
be much more
@node Saving typing with identifiers and functions
@section Saving typing with identifiers and functions
+@cindex variables
+@cindex identifiers
+
By this point, you've seen this kind of thing:
@lilypond[quote,verbatim,ragged-right]
This approach can be useful even if you are only producing
one set of parts. I use half a dozen different
-``style sheet'' files for my projects. I begin every music
+@q{style sheet} files for my projects. I begin every music
file with @code{\include "../global.ly"}, which contains
@example
For example, in LilyPond 2.4 and earlier, accents and non-English
letters were entered using LaTeX -- for example,
-"@code{No\"el}" (this would print the French word for
-`Christmas'). In LilyPond 2.6 and above, the special
-"@code{ë}" must be entered directly into the LilyPond file as an
+@samp{No\"el} (this would print the French word for
+@q{Christmas}). In LilyPond 2.6 and above, the special
+@samp{ë} must be entered directly into the LilyPond file as an
UTF-8 character. @code{convert-ly} cannot change all the LaTeX
special characters into UTF-8 characters; you must manually update
your old LilyPond files.
Now start slowly uncommenting more and more of the
@code{bass} part until you find the problem line.
+Another very useful debugging technique is constructing
+@ref{Minimal examples}.
+
+
+@node Minimal examples
+@section Minimal examples
+
+A minimal example is an example which is as small as possible. These
+examples are much easier to understand than long examples. Minimal
+examples are used for
+
+@itemize
+@item Bug reports
+@item Sending a help request to mailists
+@item Adding an example to the @uref{http://lsr@/.dsi@/.unimi/2.it/,LilyPond
+Snippet Repository}
+@end itemize
+
+To construct an example which is as small as possible, the rule is
+quite simple: remove anything which is not necessary. When trying to
+remove unnecessary parts of a file, it is a very good idea to comment
+out lines instead of deleting them. That way, if you discover that you
+actually @emph{do} need some lines, you can un-comment them, instead of
+typing them in from scratch.
+
+There are two exceptions to the @qq{as small as possible} rule:
+
+@itemize
+@item Include the @code{\version} number.
+@item If possible, use @code{\paper@{ ragged-right=##t @}} at the
+top of your example.
+@end itemize
+
+The whole point of a minimal example is to make it easy to read:
+
+@itemize
+@item Avoid using complicated notes, keys, or time signatures, unless you
+wish to demonstrate something is about the behavior of those items.
+@item Do not use \override commands unless that is the point of the
+example.
+@end itemize
+