From: Trevor Daniels Date: Wed, 9 Apr 2008 22:06:05 +0000 (+0100) Subject: Use input files or LilyPond input files consistently X-Git-Tag: release/2.11.44-1~15^2~1 X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=32cc4944ff237e7be4eb2e9036f3ed768f7368f6;p=lilypond.git Use input files or LilyPond input files consistently Change all references to LilyPond input files to use these terms and no others consistently --- diff --git a/Documentation/user/fundamental.itely b/Documentation/user/fundamental.itely index a8b7801ef4..e9e0800640 100644 --- a/Documentation/user/fundamental.itely +++ b/Documentation/user/fundamental.itely @@ -18,15 +18,15 @@ concepts and techniques required to produce equally beautiful but more complex scores. @menu -* How LilyPond files work:: +* How LilyPond input files work:: * Voices contain music:: * Contexts and engravers:: * Extending the templates:: @end menu -@node How LilyPond files work -@section How LilyPond files work +@node How LilyPond input files work +@section How LilyPond input files work The LilyPond input format is quite free-form, giving experienced users a lot of flexibility to structure their files however they @@ -191,7 +191,7 @@ For a complete definition of the input format, see @cindex Music expression, compound We saw the general organization of LilyPond input files in the -previous section, @ref{How LilyPond files work}. But we seemed to +previous section, @ref{How LilyPond input files work}. But we seemed to skip over the most important part: how do we figure out what to write after @code{\score}? @@ -1470,15 +1470,15 @@ name you like in any context that exists by using the known to LilyPond it will not cause any action to be taken. This is one of the reasons why it is highly recommended to use a context-sensitive editor with syntax highlighting for -editing LilyPond files, such as Vim, Jedit, ConTEXT or Emacs, +editing LilyPond input files, such as Vim, Jedit, ConTEXT or Emacs, since unknown property names will be highlighted differently. The @code{instrumentName} property will take effect only if it is set in the @code{Staff} context, but some properties can be set in more than one context. For example, the property @code{extraNatural} is by -default set to ##t (true) for all staves. -If it is set to ##f (false) in one particular @code{Staff} +default set to ##t (true) for all staves. +If it is set to ##f (false) in one particular @code{Staff} context it applies just to the accidentals on that staff. If it is set to false in the @code{Score} context it applies to all staves. diff --git a/Documentation/user/tutorial.itely b/Documentation/user/tutorial.itely index 6d01a52da9..0bd1a99c4f 100644 --- a/Documentation/user/tutorial.itely +++ b/Documentation/user/tutorial.itely @@ -54,20 +54,21 @@ This section gives a basic introduction to working with LilyPond. @menu * Compiling a file:: * Simple notation:: -* Working on text files:: -* How to read the manual:: +* Working on input files:: +* How to read the manual:: @end menu @node Compiling a file @subsection Compiling a file -@qq{Compiling} is the term used for processing an input text file +@qq{Compiling} is the term used for processing an input file in LilyPond format to produce a file which can be printed and -(optionally) a MIDI file which can be played. The first example -shows what a simple input text file looks like. +(optionally) a MIDI file which can be played. LilyPond input +files are simple text files. The first example +shows what a simple input file looks like. -To create sheet music, we write a text file that specifies the +To create sheet music, we write an input file that specifies the notation. For example, if we write: @example @@ -412,8 +413,8 @@ Notation Reference: @ruser{Writing pitches}, @ruser{Time signature}, @ruser{Clef}. -@node Working on text files -@subsection Working on text files +@node Working on input files +@subsection Working on input files LilyPond input files are similar to source files in many common programming languages. They are case sensitive, and white-space @@ -514,7 +515,7 @@ comments: @subsection How to read the manual LilyPond input must be surrounded by @{ @} marks or a -@code{\relative c'' @{ ... @}}, as we saw in @ref{Working on text +@code{\relative c'' @{ ... @}}, as we saw in @ref{Working on input files}. For the rest of this manual, most examples will omit this. To replicate the examples, you may copy and paste the displayed input but you @strong{must} add the @code{\relative c'' @@ -561,7 +562,7 @@ cut-&-pastable section} to the bottom of the file. There are more tips for constructing input files in -@ref{Suggestions for writing LilyPond files}. But it might be +@ref{Suggestions for writing LilyPond input files}. But it might be best to read through the rest of the tutorial first. diff --git a/Documentation/user/tweaks.itely b/Documentation/user/tweaks.itely index 3bbb34f86a..1f4e328726 100644 --- a/Documentation/user/tweaks.itely +++ b/Documentation/user/tweaks.itely @@ -3273,7 +3273,7 @@ interest are: @node Avoiding tweaks with slower processing @subsection Avoiding tweaks with slower processing -LilyPond can perform extra checks while it processes files. These +LilyPond can perform extra checks while it processes input files. These checks will take extra time to perform, but fewer manual tweaks may be required to obtain an acceptable result. If a text script or part of the lyrics extends over the margins these checks will diff --git a/Documentation/user/working.itely b/Documentation/user/working.itely index c35eca1c48..8077bb3a60 100644 --- a/Documentation/user/working.itely +++ b/Documentation/user/working.itely @@ -19,38 +19,39 @@ this chapter. @menu -* Suggestions for writing LilyPond files:: +* Suggestions for writing LilyPond input files:: * When things don't work:: * Scores and parts:: @end menu -@node Suggestions for writing LilyPond files -@section Suggestions for writing LilyPond files +@node Suggestions for writing LilyPond input files +@section Suggestions for writing LilyPond input files -Now you're ready to begin writing larger LilyPond files -- not just the -little examples in the tutorial, but whole pieces. But how should you -go about doing it? +Now you're ready to begin writing larger LilyPond input files -- +not just the little examples in the tutorial, but whole pieces. +But how should you go about doing it? -As long as LilyPond can understand your files and produces the output -that you want, it doesn't matter what your files look like. However, -there are a few other things to consider when writing LilyPond files. +As long as LilyPond can understand your input files and produce +the output that you want, it doesn't matter what your input files +look like. However, there are a few other things to consider when +writing LilyPond input files. @itemize @item What if you make a mistake? The structure of a LilyPond file can make certain errors easier (or harder) to find. -@item What if you want to share your files with somebody -else? In fact, what if you want to alter your own files in -a few years? Some LilyPond files are understandable at -first glance; other files may leave you scratching your head +@item What if you want to share your input files with somebody +else? In fact, what if you want to alter your own input files in +a few years? Some LilyPond input files are understandable at +first glance; others may leave you scratching your head for an hour. @item What if you want to upgrade your LilyPond file for use with a later version of LilyPond? The input syntax changes occasionally as LilyPond improves. Most changes can be done automatically with @code{convert-ly}, but some changes -might require manual assistance. LilyPond files can be +might require manual assistance. LilyPond input files can be structured in order to be easier (or harder) to update. @end itemize @@ -89,10 +90,10 @@ 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 @q{debug} your files. +worth it if you have to @q{debug} your input files. -@item @strong{Comment your files}. Use either bar numbers (every so often) -or +@item @strong{Comment your input files}. Use either bar numbers +(every so often) or 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 @@ -146,7 +147,7 @@ best. @subsection Large projects When working on a large project, having a clear structure to your -lilypond files becomes vital. +lilypond input files becomes vital. @itemize @@ -285,9 +286,9 @@ padText = @end lilypond Using variables is also a good way to reduce work if the -LilyPond input syntax changes (see @ref{Updating old files}). If +LilyPond input syntax changes (see @ref{Updating old input files}). If you have a single definition (such as @code{\dolce}) for all your -files (see @ref{Style sheets}), then if the syntax changes, you +input files (see @ref{Style sheets}), then if the syntax changes, you only need to update your single @code{\dolce} definition, instead of making changes throughout every @code{.ly} file. @@ -297,7 +298,7 @@ instead of making changes throughout every @code{.ly} file. The output that LilyPond produces can be heavily modified; see @ref{Tweaking output}, for details. But what if you have many -files that you want to apply your tweaks to? Or what if you +input files that you want to apply your tweaks to? Or what if you simply want to separate your tweaks from the actual music? This is quite easy to do. @@ -329,7 +330,7 @@ do something about the @code{mpdolce} and @code{tempoMark} definitions. They produce the output we desire, but we might want 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 +those definitions in our input files, and I personally find all the @code{#()} somewhat ugly. Let's hide them in another file: @example @@ -551,13 +552,13 @@ file with @code{\include "../global.ly"}, which contains @section When things don't work @menu -* Updating old files:: +* Updating old input files:: * Troubleshooting (taking it all apart):: * Minimal examples:: @end menu -@node Updating old files -@subsection Updating old files +@node Updating old input files +@subsection Updating old input files The LilyPond input syntax occasionally changes. As LilyPond itself improves, the syntax (input language) is modified accordingly. Sometimes @@ -581,7 +582,7 @@ letters were entered using LaTeX -- for example, @code{ë} 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. +your old LilyPond input files. @node Troubleshooting (taking it all apart)