]> git.donarmstrong.com Git - lilypond.git/blobdiff - Documentation/usage/suggestions.itely
Merge branch 'master' into translation
[lilypond.git] / Documentation / usage / suggestions.itely
index 9abc1712dfd66ed9e79d689b44d3ca28c63e9626..2c6fcaca8fae3331e37f59f23a0dc5c24ae5aefb 100644 (file)
@@ -8,7 +8,7 @@
     Guide, node Updating translation committishes..
 @end ignore
 
-@c \version "2.12.0"
+@c \version "2.16.0"
 
 @node Suggestions for writing files
 @chapter Suggestions for writing files
@@ -130,7 +130,7 @@ best.
 variable, it is recommended that the notes are wrapped in
 
 @example
-\transpose c natural-pitch @{...@}
+\transpose c natural-pitch @{@dots{}@}
 @end example
 
 @noindent
@@ -167,7 +167,7 @@ in a new version of LilyPond.
 violin = \relative c'' @{
 g4 c'8. e16
 @}
-...
+@dots{}
 \score @{
   \new GrandStaff @{
     \new Staff @{
@@ -177,12 +177,11 @@ g4 c'8. e16
 @}
 @end example
 
-@item @strong{Separate tweaks from music definitions}.  This
-point was made previously, but for large
-projects it is absolutely vital.  We might need to change
-the definition of @code{fthenp}, but then we only need
-to do this once, and we can still avoid touching anything
-inside @code{violin}.
+@item @strong{Separate tweaks from music definitions}.  This point was
+made previously, but for large projects it is absolutely vital.  We
+might need to change the definition of @code{fthenp}, but then we only
+need to do this once, and we can still avoid touching anything inside
+@code{violin}.
 
 @example
 fthenp = _\markup@{
@@ -205,7 +204,7 @@ investigation to determine the source of the problem.
 
 The most powerful tools for this purpose are the
 single line comment (indicated by @code{%}) and the block
-comment (indicated by @code{%@{ ... %@}}).  If you don't
+comment (indicated by @code{%@{@dots{}%@}}).  If you don't
 know where a problem is, start commenting out huge portions
 of your input file.  After you comment out a section, try
 compiling the file again.  If it works, then the problem
@@ -261,7 +260,7 @@ facility called @code{make}.  This software reads a special file called a
 @code{Makefile} that defines what files depend on what others and what
 commands you need to give the operating system to produce one file from
 another.  For example the makefile would spell out how to produce
-@code{ballad.pdf} and @code{ballad.midi} from @code{ballad.ly} by
+@file{ballad.pdf} and @file{ballad.midi} from @file{ballad.ly} by
 running Lilypond.
 
 There are times when it is a good idea to create a @code{Makefile}
@@ -281,11 +280,11 @@ See the @strong{GNU Make Manual} for full details on using
 can do.
 
 The commands to define rules in a makefile differ
-according to platform; for instance the various forms of Linux and
+according to platform; for instance the various forms of GNU/Linux and
 MacOS use @code{bash}, while Windows uses @code{cmd}.  Note that on
 MacOS X, you need to configure the system to use the command-line
 interpreter.  Here are some example makefiles, with versions for both
-Linux/MacOS and Windows.
+GNU/Linux/MacOS and Windows.
 
 The first example is for an orchestral work in four
 movements with a directory structure as follows:
@@ -320,13 +319,13 @@ Symphony/
 `-- symphonyDefs.ily
 @end example
 
-The @code{.ly} files in the @code{Scores} and
-@code{Parts} directories get their notes from @code{.ily}
-files in the @code{Notes} directory:
+The @file{.ly} files in the @file{Scores} and
+@file{Parts} directories get their notes from @file{.ily}
+files in the @file{Notes} directory:
 
 @example
 %%% top of file "symphony-cello.ly"
-\include ../definitions.ily
+\include ../symphonyDefs.ily
 \include ../Notes/cello.ily
 @end example