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 a8b7801ef45defbd1d3d2d552000a9faf5a13c0c..e9e0800640deb34759359efb0b8e9954654fb49a 100644 (file)
--- 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 6d01a52da9cb3e1af9f7e59b25b4f119d845ed76..0bd1a99c4ff0d4517d0de97d0e54fd1cbe565b54 100644 (file)
--- 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 3bbb34f86abfb6455c2554a32993adbe3977a5b5..1f4e328726abef5d0cefef1c093a1172ce2a5d7e 100644 (file)
--- 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 c35eca1c48624dcba8ffb77c5321da97d5db160a..8077bb3a6068051f0ca8b6a16c35b7c448513d04 100644 (file)
--- 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)