Doc: unify some LilyPond case spellings.

diff --git a/Documentation/extending/programming-interface.itely b/Documentation/extending/programming-interface.itely
index 8465b65b0c65ef31b2aec6904190f5274dfbad4f..1e8e92dbbd8f084ea6f6e9684dc1049d4a98a67c 100644 (file)
--- a/Documentation/extending/programming-interface.itely
+++ b/Documentation/extending/programming-interface.itely
@@ -37,10 +37,10 @@ Lilypond code blocks look like
   #@{ @var{Lilypond code} #@}
 @end example
 They can be used anywhere where you can write Scheme code: the Scheme
-reader actually is changed for accommodating Lilypond code blocks.  When
-the Lilypond code block is being read, it is parsed superficially and
-replaced by a call to the Lilypond @code{parser} which is executed at
-runtime to interpret the Lilypond code block.
+reader actually is changed for accommodating LilyPond code blocks.  When
+the LilyPond code block is being read, it is parsed superficially and
+replaced by a call to the LilyPond @code{parser} which is executed at
+runtime to interpret the LilyPond code block.
 
 The point of the superficial parsing is the interpretation of @code{$}
 signs which can be used for splicing in expressions from the surrounding
@@ -49,15 +49,15 @@ parameters).  @code{$} can be used in the following ways:
 
 @table @code
 @item $$
-just passes a single @code{$} to the Lilypond parser.
+just passes a single @code{$} to the LilyPond parser.
 @item $@var{form}
 will evaluate the Scheme form at runtime and splice its value as an
-identifier @code{\form} into the Lilypond parser.  Depending on the
+identifier @code{\form} into the LilyPond parser.  Depending on the
 value type, it may be interpreted as several different syntactic
 entities.
 @item #$@var{form}
 will evaluate the Scheme form at runtime and splice its value as a
-Scheme expression into the Lilypond parser.
+Scheme expression into the LilyPond parser.
 @item #@var{form}
 Forms in Scheme expressions started with @code{#} are read and parsed
 recursively for @code{$} signs.  Those are treated as follows:
@@ -65,7 +65,7 @@ recursively for @code{$} signs.  Those are treated as follows:
 splices the value of the variable into the surrounding expression.
 @item #@dots{}($ @var{form} @dots{})
 splices the value of the form into the surrounding expression.  As
-opposed to a Lilypond level @code{$@var{form}}, you need to separate the
+opposed to a LilyPond level @code{$@var{form}}, you need to separate the
 form with a blank, making @code{$} be recognizable as a separate Scheme
 symbol.
 @end table
@@ -77,14 +77,14 @@ music events gets turned into a sequential music expression.
 
 @node Scheme functions
 @section Scheme functions
-@cindex Scheme functions (Lilypond syntax)
+@cindex Scheme functions (LilyPond syntax)
 
 @emph{Scheme functions} are Scheme procedures that can create Scheme
-expressions from input written in Lilypond syntax.  They can be called
+expressions from input written in LilyPond syntax.  They can be called
 in pretty much all places where using @code{#} for specifying a value in
 Scheme syntax is allowed.  While Scheme has functions of its own, this
 chapter is concerned with @emph{syntactic} functions, functions that
-receive arguments specified in Lilypond syntax.
+receive arguments specified in LilyPond syntax.
 
 @menu
 * Scheme function definitions::
@@ -111,7 +111,7 @@ where
 
 @multitable @columnfractions .33 .66
 @item @code{parser}
-@tab needs to be literally @code{parser} in order to give Lilypond code
+@tab needs to be literally @code{parser} in order to give LilyPond code
 blocks (@code{#@{}@dots{}@code{#@}}) access to the parser.
 
 @item @code{@var{argN}}
@@ -124,7 +124,7 @@ recognized by the parser, see below.  There is also a special form
 @code{(@emph{predicate?} @emph{default})} for specifying optional
 arguments.  If the actual argument is missing when the function is being
 called, the default value is substituted instead.  Default values are
-evaluated at definition time (including Lilypond code blocks!), so if
+evaluated at definition time (including LilyPond code blocks!), so if
 you need a default calculated at runtime, instead write a special value
 you can easily recognize.  If you write the predicate in parentheses but
 don't follow it with a default value, @code{#f} is used as the default.
@@ -147,12 +147,12 @@ given the correct @code{origin}.
 
 @noindent
 Some type predicates are specially recognized by the parser and will
-make the parser look for the respective arguments in Lilypond syntax
+make the parser look for the respective arguments in LilyPond syntax
 rather than in Scheme syntax.  Currently these are @code{ly:music?},
 @code{markup?}, @code{ly:pitch?}, and @code{ly:duration?}.
 
 If you really want to input one of the special items as a Scheme rather
-than a Lilypond expression, you may write them as a Scheme expression
+than a LilyPond expression, you may write them as a Scheme expression
 that calls @code{ly:export} at its outermost level.
 
 Other type predicates, including user-defined ones, will make the
@@ -201,7 +201,7 @@ is used in a place where such optional parts could be considered either
 part of the music argument or not.
 
 In those rare cases, you have to delimit your music arguments
-appropriately to spare Lilypond from getting confused.
+appropriately to spare LilyPond from getting confused.
 
 @node Void scheme functions
 @subsection Void scheme functions
@@ -514,7 +514,7 @@ is equivalent to:
 @noindent
 This example demonstrates the main translation rules between regular
 LilyPond markup syntax and Scheme markup syntax.  Using @code{#@{
-@dots{} #@}} for entering in Lilypond syntax will often be most
+@dots{} #@}} for entering in LilyPond syntax will often be most
 convenient, but we explain how to use the @code{markup} macro to get a
 Scheme-only solution.