]> git.donarmstrong.com Git - lilypond.git/blob - Documentation/usage/updating.itely
06a960ac8a866faff27da9fece4208a96d395a78
[lilypond.git] / Documentation / usage / updating.itely
1 @c -*- coding: utf-8; mode: texinfo; -*-
2
3 @ignore
4     Translation of GIT committish: FILL-IN-HEAD-COMMITTISH
5
6     When revising a translation, copy the HEAD committish of the
7     version that you are working on.  For details, see the Contributors'
8     Guide, node Updating translation committishes..
9 @end ignore
10
11 @c \version "2.16.0"
12
13
14 @node Updating files with convert-ly
15 @chapter Updating files with @command{convert-ly}
16
17 @cindex Updating a LilyPond file
18 @cindex convert-ly
19
20 The LilyPond input syntax is routinely changed to simplify it or improve
21 it in different ways.  As a side effect of this, the LilyPond interpreter
22 often is no longer compatible with older input files.  To remedy this,
23 the program @command{convert-ly} can be used for upgrading files
24 to newer versions of LilyPond.
25
26 @menu
27 * Why does the syntax change?::
28 * Invoking convert-ly::
29 * Command line options for convert-ly::
30 * Problems running convert-ly::
31 * Manual conversions::
32 @end menu
33
34
35 @node Why does the syntax change?
36 @section Why does the syntax change?
37
38 @cindex convert-ly
39 @cindex updating old input files
40
41 The LilyPond input syntax occasionally changes.  As LilyPond
42 itself improves, the syntax (input language) is modified
43 accordingly.  Sometimes these changes are made to make the input
44 easier to read and write or sometimes the changes are made to
45 accommodate new features of LilyPond.
46
47 For example, all @code{\paper} and @code{\layout} property names
48 are supposed to be written in the form @code{first-second-third}.
49 However, in version 2.11.60, we noticed that the
50 @code{printallheaders} property did not follow this convention.
51 Should we leave it alone (confusing new users who must deal with
52 an inconsistent input format), or change it (annoying old users
53 with existing scores)?  In this case, we decided to change the
54 name to @code{print-all-headers}.  Fortunately, this change can be
55 automated with our @command{convert-ly} tool.
56
57 Unfortunately, @command{convert-ly} cannot handle all input changes.
58 For example, in LilyPond 2.4 and earlier, accents and non-English
59 letters were entered using LaTeX -- displaying the French word for
60 Christmas was entered as @code{No\"el}.  But in LilyPond
61 @c keep "-matching straight in fancy editors
62 2.6 and above, the special @code{ë} must be entered directly into
63 the LilyPond file as an UTF-8 character.  @command{convert-ly} cannot
64 change all the LaTeX special characters into UTF-8 characters; you
65 must manually update your old LilyPond input files.
66
67 The conversion rules of @command{convert-ly} work using text pattern
68 matching and replacement rather than a thorough understanding of
69 LilyPond.  This has several consequences:
70 @itemize @bullet
71 @item
72 The reliability of the conversion depends on the quality of each
73 applied rule set and on the complexity of the respective change.
74 Sometimes conversions may require manual fixes, so the old version
75 should be kept available for comparison.
76 @item
77 Only conversions to newer formats are possible: there are no rule
78 sets for downgrading.  So the main working copy of a LilyPond file
79 should only be upgraded when older versions of LilyPond no longer
80 need to be supported.  Version control systems such as Git might
81 help with maintaining multiple versions.
82 @item
83 LilyPond and Scheme themselves are quite robust against creatively
84 placed and omitted spaces, but the rules used by
85 @command{convert-ly} tend to make some stylistic assumptions.
86 Following the style used in the manuals is the safest bet for
87 painless upgrades, particularly as the manuals themselves are
88 upgraded using @command{convert-ly}.
89 @end itemize
90
91
92 @node Invoking convert-ly
93 @section Invoking @command{convert-ly}
94
95 @command{convert-ly} uses @code{\version} statements in the input
96 file to detect the old version number.  In most cases, to upgrade
97 your input file it is sufficient to run
98
99 @example
100 convert-ly -e myfile.ly
101 @end example
102
103 @noindent
104 in the directory containing the file.  This will upgrade
105 @file{myfile.ly} in-place and preserve the original file in
106 @file{myfile.ly~}.
107
108 @warning{@command{convert-ly} always converts up to the last
109 syntax change handled by it.  This means that the @code{\version}
110 number left in the file is usually lower than the version of
111 @command{convert-ly} itself.}
112
113 To convert all the input files in a directory together use
114
115 @example
116 convert-ly -e *.ly
117 @end example
118
119 Alternatively, if you want to specify a different name for the
120 upgraded file, preserving the original file and name unchanged,
121 use
122
123 @example
124 convert-ly myfile.ly > mynewfile.ly
125 @end example
126
127 The program will list the version numbers for which conversions
128 have been made.  If no version numbers are listed the file is
129 already up to date.
130
131 MacOS@tie{}X users may execute these commands under the menu entry
132 @code{Compile > Update syntax}.
133
134 Windows users should enter these commands in a Command Prompt
135 window, which is usually found under
136 @code{Start > Accessories > Command Prompt}.
137
138
139 @node Command line options for convert-ly
140 @section Command line options for @command{convert-ly}
141
142 The program is invoked as follows:
143
144 @example
145 convert-ly [@var{option}]@dots{} @var{filename}@dots{}
146 @end example
147
148 The following options can be given:
149
150 @table @code
151 @item -d, --diff-version-update
152 increase the @code{\version} string only if the file has actually
153 been changed.  In that case, the version header will correspond to
154 the version after the last actual change.  Without that option,
155 the version will reflect the last @emph{attempted} conversion.
156
157 @item -e, --edit
158 Apply the conversions direct to the input file, modifying it
159 in-place.  The original file is renamed as @file{myfile.ly~}.  This
160 backup file may be a hidden file on some operating systems.
161
162 @item -b, --backup-numbered
163 When used with the @samp{-e} option, number the backup files so that
164 no previous version is overwritten.  The backup files may be hidden
165 on some operating systems.
166
167 @item -f, --from=@var{from-patchlevel}
168 Set the version to convert from.  If this is not set, @command{convert-ly}
169 will guess this, on the basis of @code{\version} strings in the file.
170 E.g. @option{--from=2.10.25}
171
172 @item -h, --help
173 Print usage help.
174
175 @item -l @var{loglevel}, --loglevel=@var{loglevel}
176 Set the output verbosity to @var{loglevel}. Possible values, in upper
177 case, are @code{PROGRESS} (the default), @code{NONE}, @code{WARNING},
178 @code{ERROR} and @code{DEBUG}.
179
180 @item -n, --no-version
181 Normally, @command{convert-ly} adds a @code{\version} indicator
182 to the output.  Specifying this option suppresses this.
183
184 @item -s, --show-rules
185 Show all known conversions and exit.
186
187 @item -t, --to=@var{to-patchlevel}
188 Explicitly set which @code{\version} to convert to, otherwise the
189 default is the most current value.  It must be higher than the
190 starting version.
191
192 @example
193 convert-ly --to=2.14.1 myfile.ly
194 @end example
195
196 @end table
197
198 To upgrade LilyPond fragments in texinfo files, use
199
200 @example
201 convert-ly --from=@dots{} --to=@dots{} --no-version *.itely
202 @end example
203
204 To see the changes in the LilyPond syntax between two versions, use
205
206 @example
207 convert-ly --from=@dots{} --to=@dots{} -s
208 @end example
209
210
211 @node Problems running convert-ly
212 @section Problems running @code{convert-ly}
213
214 When running convert-ly in a Command Prompt window under Windows
215 on a file which has spaces in the filename or in the path to it,
216 it is necessary to surround the entire input file name with three
217 (!) sets of double quotes:
218
219 @example
220 convert-ly """D:/My Scores/Ode.ly""" > "D:/My Scores/new Ode.ly"
221 @end example
222
223 If the simple @command{convert-ly -e *.ly} command fails because the
224 expanded command line becomes too long, the @command{convert-ly}
225 command may be placed in a loop instead.  This example for UNIX
226 will upgrade all @file{.ly} files in the current directory
227
228 @example
229 for f in *.ly; do convert-ly -e $f; done;
230 @end example
231
232 In the Windows Command Prompt window the corresponding command is
233
234 @example
235 for %x in (*.ly) do convert-ly -e """%x"""
236 @end example
237
238 Not all language changes are handled.  Only one output option can be
239 specified.  Automatically updating scheme and LilyPond scheme
240 interfaces is quite unlikely; be prepared to tweak scheme code
241 manually.
242
243
244 @node Manual conversions
245 @section Manual conversions
246
247 In theory, a program like @command{convert-ly} could handle any
248 syntax change.  After all, a computer program interprets the old
249 version and the new version, so another computer program can
250 translate one file into another@footnote{At least, this is
251 possible in any LilyPond file which does not contain scheme.  If
252 there is scheme in the file, then the LilyPond file contains a
253 Turing-complete language, and we run into problems with the famous
254 @qq{Halting Problem} in computer science.}.
255
256 However, the LilyPond project has limited resources: not all
257 conversions are performed automatically.  Below is a list of known
258 problems.
259
260
261 @verbatim
262 1.6->2.0:
263  Doesn't always convert figured bass correctly, specifically things like {<
264 >}.  Mats' comment on working around this:
265    To be able to run convert-ly
266    on it, I first replaced all occurrences of '{<' to some dummy like '{#'
267    and similarly I replaced '>}' with '&}'.  After the conversion, I could
268    then change back from '{ #' to '{ <' and from '& }' to '> }'.
269  Doesn't convert all text markup correctly.  In the old markup syntax,
270  it was possible to group a number of markup commands together within
271 parentheses, e.g.
272    -#'((bold italic) "string")
273    This will incorrectly be converted into
274    -\markup{{\bold italic} "string"}
275    instead of the correct
276    -\markup{\bold \italic "string"}
277 2.0->2.2:
278  Doesn't handle \partcombine
279  Doesn't do \addlyrics => \lyricsto, this breaks some scores with multiple
280 stanzas.
281 2.0->2.4:
282  \magnify isn't changed to \fontsize.
283     - \magnify #m => \fontsize #f, where f = 6ln(m)/ln(2)
284  remove-tag isn't changed.
285     - \applyMusic #(remove-tag '. . .) => \keepWithTag #'. . .
286  first-page-number isn't changed.
287     - first-page-number no => print-first-page-number = ##f
288  Line breaks in header strings aren't converted.
289     - \\\\  as line break in \header strings => \markup \center-align <
290       "First Line" "Second Line" >
291  Crescendo and decrescendo terminators aren't converted.
292     - \rced => \!
293     - \rc => \!
294 2.2->2.4:
295  \turnOff (used in \set Staff.VoltaBracket = \turnOff) is not properly
296 converted.
297 2.4.2->2.5.9
298  \markup{ \center-align <{ ... }> } should be converted to:
299  \markup{ \center-align {\line { ... }} }
300  but now, \line is missing.
301 2.4->2.6
302  Special LaTeX characters such as $~$ in text are not converted to UTF8.
303 2.8
304  \score{} must now begin with a music expression.  Anything else
305  (particularly \header{}) must come after the music.
306 @end verbatim
307
308