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"
@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
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 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
+@item Do not use @code{\override} commands unless that is the point of the
example.
@end itemize