@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.
@itemize @bullet
@item @strong{Include @code{\version} numbers in every file}. Note that all
-templates contain a @code{\version "2.9.13"} string. We
+templates contain a @code{\version "2.11.15"} string. We
highly recommend that you always include the @code{\version}, no matter
how small your file is. Speaking from personal experience, it's
quite frustrating to try to remember which version of LilyPond you were
using a few years ago. @code{convert-ly} requires you to declare
which version of LilyPond you used.
-@item @strong{Include checks}: @ref{Bar check} and @ref{Octave check}. If
-you
+@item @strong{Include checks}: @ref{Bar check}, @ref{Octave check} and
+@ref{Barnumber check}. If you
include checks every so often, then if you make a mistake, you can pinpoint
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
is quite easy to do.
Let's look at an example. Don't worry if you don't understand
-the parts with all the #(). This is explained in
+the parts with all the @code{#()}. This is explained in
@ref{Advanced tweaks with Scheme}.
@lilypond[quote,verbatim,ragged-right]
to use them in another piece. We could simply copy-and-paste them
at the top of every file, but that's an annoyance. It also leaves
those definitions in our music files, and I personally find all
-the #() somewhat ugly. Let's hide them in another file:
+the @code{#()} somewhat ugly. Let's hide them in another file:
@example
%%% save this to a file called "definitions.ly"
@example
%%% global.ly
-\version "2.9.13"
+\version "2.11.15"
#(ly:set-option 'point-and-click #f)
\include "../init/init-defs.ly"
\include "../init/init-layout.ly"
@code{convert-ly}. For details about how to run this program, see
@ref{Updating files with convert-ly}.
-Unforunately, @code{convert-ly} cannot handle all input changes. It
+Unfortunately, @code{convert-ly} cannot handle all input changes. It
takes care of simple search-and-replace changes (such as @code{raggedright}
becoming @code{ragged-right}), but some changes are too
complicated. The syntax changes that @code{convert-ly} cannot handle
@node Minimal examples
@section Minimal examples
-A minimal example is an example which is small as possible. These
+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
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
+actually @emph{do} need some lines, you can uncomment 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.
+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
+wish to demonstrate something is about the behavior of those items.
+@item Do not use @code{\override} commands unless that is the point of the
example.
@end itemize
projects / lilypond.git / blobdiff