Doc: Updates to CG, Extending, LM and Paper-defaults.ly

Better code formatting in some alists.
Previously, the 110-character lines
made it difficult to read; the new
version is also in line with what
the NR says.

Extending: comment TODO remark Telling
the user that he might be confused about
something (while he doesn’t understand
what exactly that is) only adds to confusion;

Use a properly formatted example;
This should actually show how reformatting
Scheme code makes it easier to read; however,
it uses tabs and the result in both HTML
and PDF is messy.

The new version uses normal spaces only
and should be consistent as well as clear.

Other minor wording and punctuation improvements

Capitalize LilyPond correctly

Fix typo in LM
There was an unmatched parenthesis in the text;
changed into a comma.

8 files changed, 82 insertions, 61 deletions

diff --git a/Documentation/contributor/administration.itexi b/Documentation/contributor/administration.itexi
index ec8e751a03..a392f7d660 100644
--- a/Documentation/contributor/administration.itexi
+++ b/Documentation/contributor/administration.itexi
@@ -803,7 +803,7 @@ Should we change the "structure" / "framework" for bounties?
 (prep: 2 hours.  discuss: 10 hours)
 
 @item @strong{code readability}:
-"Our aim when producing source code for Lilypond in whatever
+"Our aim when producing source code for LilyPond in whatever
 language is that it should be totally comprehensible to a
 relatively inexperienced developer at the second reading."
 
diff --git a/Documentation/contributor/doc-work.itexi b/Documentation/contributor/doc-work.itexi
index f8ea33932e..0435b96265 100644
--- a/Documentation/contributor/doc-work.itexi
+++ b/Documentation/contributor/doc-work.itexi
@@ -1544,7 +1544,7 @@ build/tempdocs/pitches/out/pitches.html
 @end example
 
 According to
-@uref{http://code.google.com/p/lilypond/issues/detail?id=1236,Lilypond issue 1236},
+@uref{http://code.google.com/p/lilypond/issues/detail?id=1236,LilyPond issue 1236},
 the location of the LilyPond Git tree is taken from @code{$LILYPOND_GIT}
 if specified, otherwise it is auto-detected.
 
diff --git a/Documentation/contributor/programming-work.itexi b/Documentation/contributor/programming-work.itexi
index 99dc79da4a..66a792066c 100644
--- a/Documentation/contributor/programming-work.itexi
+++ b/Documentation/contributor/programming-work.itexi
@@ -771,8 +771,8 @@ The error functions come in three different flavors: fatal error messages,
 programming error messages and normal error messages.  Errors written
 by the @code{error ()} function will cause LilyPond to exit immediately,
 errors by @code{Input::error ()} will continue the compilation, but
-return a non-zero return value of the lilypond call (i.e. indicate an 
-unsuccessful program execution).  All other errors will be printed on the 
+return a non-zero return value of the LilyPond call (i.e. indicate an
+unsuccessful program execution).  All other errors will be printed on the
 console, but not exit LilyPond or indicate an unsuccessful return code.
 Their only differences to a warnings are the displayed text and that
 they will be shown with loglevel @code{ERROR}.
@@ -882,7 +882,7 @@ treated as if @code{Input::error} was called.
 
 The most commonly used tool for debugging LilyPond is the GNU
 debugger gdb.  The gdb tool is used for investigating and debugging
-core Lilypond code written in C++.  Another tool is available for
+core LilyPond code written in C++.  Another tool is available for
 debugging Scheme code using the Guile debugger.  This section
 describes how to use both gdb and the Guile Debugger.
 
@@ -935,7 +935,7 @@ information from the LilyPond binary.
 
 @subheading Typical gdb usage
 
-Once you have compiled the Lilypond image with the necessary
+Once you have compiled the LilyPond image with the necessary
 debugging information it will have been written to a location in a
 subfolder of your current working directory:
 
@@ -1109,7 +1109,7 @@ commands.  For a listing of these commands, type:
 debug> help
 @end example
 
-Alternatively you may code the breakpoints in your Lilypond source
+Alternatively you may code the breakpoints in your LilyPond source
 file using a command such as:
 
 @example
@@ -1232,9 +1232,9 @@ In order to use the graphviz utility, the @file{.ly} file must include
 grobs and symbols that should be tracked.  An example of this
 is found in @file{input/regression/graphviz.ly}.
 
-@item Run lilypond with output sent to a log file
+@item Run LilyPond with output sent to a log file
 
-The Graphviz data is sent to stderr by lilypond, so it is
+The Graphviz data is sent to stderr by LilyPond, so it is
 necessary to redirect stderr to a logfile:
 
 @example
@@ -1243,11 +1243,11 @@ lilypond graphviz.ly 2> graphviz.log
 
 @item Edit the logfile
 
-The logfile has standard lilypond output, as well as the Graphviz
+The logfile has standard LilyPond output, as well as the Graphviz
 output data.  Delete everything from the beginning of the file
 up to but not including the first occurrence of @code{digraph}.
 
-Also, delete the final lilypond message about success from the end
+Also, delete the final LilyPond message about success from the end
 of the file.
 
 @item Process the logfile with @code{dot}
@@ -1263,10 +1263,10 @@ dot -Tpdf graphviz.log > graphviz.pdf
 
 The pdf file can then be viewed with any pdf viewer.
 
-When compiled with @option{-DDEBUG}, lilypond may run slower
+When compiled with @option{-DDEBUG}, LilyPond may run slower
 than normal.  The original configuration can be restored by rerunning
 @code{./configure} with @option{--disable-checking}.  Then
-rebuild lilypond with
+rebuild LilyPond with
 
 @example
 make -C lily clean && make -C lily
@@ -1383,7 +1383,7 @@ LILYPOND_BUILD_DIR=../build-lilypond/ scripts/auxiliar/update-with-convert-ly.sh
 @subsection Manually update documentation
 
 Where the convert-ly rule is not able to automatically update the inline
-lilypond code in the documentation (i.e. if a NOT_SMART rule is used), the
+LilyPond code in the documentation (i.e. if a NOT_SMART rule is used), the
 documentation must be manually updated.  The inline snippets that require
 changing must be changed in the English version of the docs and all
 translated versions.  If the inline code is not changed in the
@@ -1818,7 +1818,8 @@ time and to prevent you some major headaches.
 
 @node Purity in LilyPond
 @subsection Purity in LilyPond
-Pure properties in LilyPond that do not have any @q{side effects}.
+Pure properties in LilyPond are properties that do not have any
+@q{side effects}.
 That is, looking up a pure property should never result in calls to the
 following functions:
 @itemize
@@ -1899,7 +1900,7 @@ of a spanner broken at given starting and ending columns.
 @node How purity is defined and stored
 @subsection How purity is defined and stored
 Purity is defined in LilyPond with the creation of an unpure-pure container
-(unpure is not a word, but hey, neither was Lilypond until the 90s).  For example:
+(unpure is not a word, but hey, neither was LilyPond until the 90s).  For example:
 
 @example
 #(define (foo grob)
@@ -2022,7 +2023,7 @@ instead of pure height.
 @node LilyPond scoping
 @section LilyPond scoping
 
-The Lilypond language has a concept of scoping, i.e. you can do:
+The LilyPond language has a concept of scoping, i.e. you can do:
 
 @example
 foo = 1
@@ -2038,7 +2039,7 @@ is translated in to a scheme variable definition.
 This implemented using modules, with each scope being an anonymous
 module that imports its enclosing scope's module.
 
-Lilypond's core, loaded from @file{.scm} files, is usually placed in the
+LilyPond's core, loaded from @file{.scm} files, is usually placed in the
 @code{lily} module, outside the @file{.ly} level.  In the case of
 
 @example
@@ -2141,7 +2142,7 @@ but not @code{scm_is_equal}.
 Return @code{true} if @var{b} is @code{SCM_BOOL_T}, else return @code{false}.
 
 This should be used instead of @code{scm_is_true} and
-@code{scm_is_false} for properties since in Lilypond, unset properties
+@code{scm_is_false} for properties since in LilyPond, unset properties
 are read as an empty list, and by convention unset Boolean properties
 default to false.  Since both @code{scm_is_true} and
 @code{scm_is_false} only compare with @code{##f} in line with what
@@ -2156,7 +2157,7 @@ Behave the same as scm_is_[something] would do if it existed.
 
 Test whether the type of @var{s} is [type].
 [type] is a LilyPond-only set of values (direction, axis...).  More
-often than not, the code checks Lilypond specific C++-implemented
+often than not, the code checks LilyPond specific C++-implemented
 types using
 
 @subsubheading [Type *] unsmob<Type> (SCM s)
diff --git a/Documentation/contributor/release-work.itexi b/Documentation/contributor/release-work.itexi
index 05241fc7ba..3869505630 100644
--- a/Documentation/contributor/release-work.itexi
+++ b/Documentation/contributor/release-work.itexi
@@ -108,7 +108,7 @@ VERSION_STABLE = the current stable version (probably no change here)
 @end itemize
 
 @item
-update the @qq{Welcome to Lilypond} version numbers to the version about to be
+update the @qq{Welcome to LilyPond} version numbers to the version about to be
 released
 
 @end itemize
diff --git a/Documentation/extending/programming-interface.itely b/Documentation/extending/programming-interface.itely
index 861105029f..f54b1ad0ce 100644
--- a/Documentation/extending/programming-interface.itely
+++ b/Documentation/extending/programming-interface.itely
@@ -1333,7 +1333,7 @@ set at fixed values with @code{\override}, e.g.
 \override Stem.thickness = #2.0
 @end example
 
-Properties can also be set to a Scheme procedure,
+Properties can also be set to a Scheme procedure:
 
 @lilypond[fragment,verbatim,quote]
 \override Stem.thickness = #(lambda (grob)
diff --git a/Documentation/extending/scheme-tutorial.itely b/Documentation/extending/scheme-tutorial.itely
index 8588ff2685..f8f23a5fa4 100644
--- a/Documentation/extending/scheme-tutorial.itely
+++ b/Documentation/extending/scheme-tutorial.itely
@@ -72,7 +72,7 @@ see @rlearning{Other sources of information}.  Alternatively, Windows
 users may simply choose @q{Run} from the Start menu and enter
 @q{guile}.
 
-However, a hands-on Scheme sandbox with all of Lilypond loaded is
+However, a hands-on Scheme sandbox with all of LilyPond loaded is
 available with this command line:
 @example
 lilypond scheme-sandbox
@@ -680,7 +680,7 @@ feasible.
 
 Another way to call the Scheme interpreter from LilyPond is the use of
 dollar@tie{}@code{$} instead of a hash mark for introducing Scheme
-expressions.  In this case, Lilypond evaluates the code right after the
+expressions.  In this case, LilyPond evaluates the code right after the
 lexer has read it.  It checks the resulting type of the Scheme
 expression and then picks a token type (one of several
 @code{xxx_IDENTIFIER} in the syntax) for it.  It creates a @emph{copy}
@@ -688,18 +688,18 @@ of the value and uses that for the value of the token.  If the value of
 the expression is void (Guile's value of @code{*unspecified*}), nothing
 at all is passed to the parser.
 
-This is, in fact, exactly the same mechanism that Lilypond employs when
+This is, in fact, exactly the same mechanism that LilyPond employs when
 you call any variable or music function by name, as @code{\name}, with
-the only difference that the name is determined by the Lilypond lexer
+the only difference that the name is determined by the LilyPond lexer
 without consulting the Scheme reader, and thus only variable names
-consistent with the current Lilypond mode are accepted.
-
-The immediate action of @code{$} can lead to surprises, @ref{Input
-variables and Scheme}.  Using @code{#} where the parser supports it
-is usually preferable.  Inside of music expressions, expressions
-created using @code{#} @emph{are} interpreted as music.  However,
-they are @emph{not} copied before use.  If they are part of some
-structure that might still get used, you may need to use
+consistent with the current LilyPond mode are accepted.
+
+The immediate action of @code{$} can lead to surprises, see
+@ref{Importing Scheme in LilyPond}.  Using @code{#} where the
+parser supports it is usually preferable.  Inside of music expressions,
+expressions created using @code{#} @emph{are} interpreted as
+music.  However, they are @emph{not} copied before use.  If they are
+part of some structure that might still get used, you may need to use
 @code{ly:music-deep-copy} explicitly.
 
 @funindex $@@
@@ -731,11 +731,11 @@ as follows:
 @end example
 
 For the rest of this section, we will assume that the data is entered
-in a music file, so we add@tie{}@code{#}s at the beginning of each Scheme
+in a music file, so we add a @code{#} at the beginning of each Scheme
 expression.
 
 All of the top-level Scheme expressions in a LilyPond input file can
-be combined into a single Scheme expression by the use of the
+be combined into a single Scheme expression by use of the
 @code{begin} statement:
 
 @example
@@ -773,8 +773,8 @@ twentyFour = #(* 2 twelve)
 which would result in the number 24 being stored in the
 LilyPond (and Scheme) variable @code{twentyFour}.
 
-The usual way to refer to Lilypond variables, @ref{LilyPond Scheme
-syntax}, is to call them using a backslash, i.e., @code{\twentyFour}.
+The usual way to refer to LilyPond variables is to call them using a
+backslash, i.e., @code{\twentyFour} (see @ref{LilyPond Scheme syntax}).
 Since this creates a copy of the value for most of LilyPond's internal
 types, in particular music expressions, music functions don't usually
 create copies of material they change.  For this reason, music
@@ -870,7 +870,7 @@ $(make-sequential-music newLa)
 You can use @code{$} with a Scheme expression anywhere you could use
 @code{\@var{name}} after having assigned the Scheme expression to a
 variable @var{name}.  This replacement happens in the @q{lexer}, so
-Lilypond is not even aware of the difference.
+LilyPond is not even aware of the difference.
 
 One drawback, however, is that of timing.  If we had been using @code{$}
 instead of @code{#} for defining @code{newLa} in the above example, the
@@ -1105,7 +1105,7 @@ to create complicated music functions.
 
 When writing a music function it is often instructive to inspect how
 a music expression is stored internally.  This can be done with the
-music function @code{\displayMusic}
+music function @code{\displayMusic}.
 
 @example
 @{
@@ -1157,7 +1157,7 @@ your port and reuse it:
 @end example
 
 Guile's manual describes ports in detail.  Closing the port is actually
-only necessary if you need to read the file before Lilypond finishes; in
+only necessary if you need to read the file before LilyPond finishes; in
 the first example, we did not bother to do so.
 
 A bit of reformatting makes the above information easier to read:
@@ -1165,13 +1165,13 @@ A bit of reformatting makes the above information easier to read:
 @example
 (make-music 'SequentialMusic
   'elements (list
-	     (make-music 'NoteEvent
+             (make-music 'NoteEvent
                'articulations (list
-			       (make-music 'AbsoluteDynamicEvent
-				 'text
-				 "f"))
-	       'duration (ly:make-duration 2 0 1/1)
-	       'pitch    (ly:make-pitch 0 0 0))))
+                               (make-music 'AbsoluteDynamicEvent
+                                           'text
+                                           "f"))
+               'duration (ly:make-duration 2 0 1/1)
+               'pitch    (ly:make-pitch 0 0 0))))
 @end example
 
 A @code{@{ @dots{} @}} music sequence has the name
@@ -1189,9 +1189,11 @@ interpreted as well as displayed.  To avoid interpretation, write
 @node Music properties
 @subsection Music properties
 
+@ignore
 TODO -- make sure we delineate between @emph{music} properties,
 @emph{context} properties, and @emph{layout} properties.  These
 are potentially confusing.
+@end ignore
 
 Let's look at an example:
 
@@ -1244,7 +1246,7 @@ expression.
 @end example
 
 Then the note pitch is accessed through the @code{'pitch} property
-of the @code{NoteEvent} object,
+of the @code{NoteEvent} object.
 
 @example
 #(display-scheme-music
@@ -1254,7 +1256,7 @@ of the @code{NoteEvent} object,
 (ly:make-pitch 0 0 0)
 @end example
 
-The note pitch can be changed by setting this @code{'pitch} property,
+The note pitch can be changed by setting this @code{'pitch} property.
 
 @funindex \displayLilyMusic
 
@@ -1309,7 +1311,7 @@ The bad news is that the @code{SlurEvent} expressions
 must be added @q{inside} the note (in its @code{articulations}
 property).
 
-Now we examine the input,
+Now we examine the input.
 
 @example
 \displayMusic a'
@@ -1374,7 +1376,7 @@ the articulation to an empty chord,
 
 @noindent
 but for the sake of this example, we will learn how to do this in
-Scheme.  We begin by examining our input and desired output,
+Scheme.  We begin by examining our input and desired output.
 
 @example
 %  input
@@ -1518,7 +1520,7 @@ addAccent = #(define-music-function (note-event)
   note-event)
 @end example
 
-We may verify that this music function works correctly,
+We may verify that this music function works correctly:
 
 @example
 \displayMusic \addAccent c4
diff --git a/Documentation/learning/tweaks.itely b/Documentation/learning/tweaks.itely
index 6d8217d12d..8aeb618952 100644
--- a/Documentation/learning/tweaks.itely
+++ b/Documentation/learning/tweaks.itely
@@ -109,7 +109,7 @@ shape.  Objects with an extended shape like these are called
 
 Spanners cannot be tweaked after their creation.  This includes both
 @code{StaffSymbol} and @code{LedgerLineSpanner} which continue
-throughout the score (except if they are terminated by the
+throughout the score, except if they are terminated by the
 @code{\stopStaff} command and then recreated using @code{\startStaff}
 command.
 
diff --git a/ly/paper-defaults-init.ly b/ly/paper-defaults-init.ly
index a8d7c7da30..a106ba9a10 100644
--- a/ly/paper-defaults-init.ly
+++ b/ly/paper-defaults-init.ly
@@ -60,14 +60,32 @@
   %% Flexible vertical spacing
   %%
   %% Note: these are not scaled; they are in staff-spaces.
-  system-system-spacing = #'((basic-distance . 12) (minimum-distance . 8) (padding . 1) (stretchability . 60))
-  score-system-spacing = #'((basic-distance . 14) (minimum-distance . 8) (padding . 1) (stretchability . 120))
-  markup-system-spacing = #'((basic-distance . 5) (padding . 0.5) (stretchability . 30))
-  score-markup-spacing = #'((basic-distance . 12) (padding . 0.5) (stretchability . 60))
-  markup-markup-spacing = #'((basic-distance . 1) (padding . 0.5))
-  top-system-spacing = #'((basic-distance . 1) (minimum-distance . 0) (padding . 1))
-  top-markup-spacing = #'((basic-distance . 0) (minimum-distance . 0) (padding . 1))
-  last-bottom-spacing = #'((basic-distance . 1) (minimum-distance . 0) (padding . 1) (stretchability . 30))
+  system-system-spacing = #'((basic-distance . 12)
+                             (minimum-distance . 8)
+                             (padding . 1)
+                             (stretchability . 60))
+  score-system-spacing = #'((basic-distance . 14)
+                            (minimum-distance . 8)
+                            (padding . 1)
+                            (stretchability . 120))
+  markup-system-spacing = #'((basic-distance . 5)
+                             (padding . 0.5)
+                             (stretchability . 30))
+  score-markup-spacing = #'((basic-distance . 12)
+                            (padding . 0.5)
+                            (stretchability . 60))
+  markup-markup-spacing = #'((basic-distance . 1)
+                             (padding . 0.5))
+  top-system-spacing = #'((basic-distance . 1)
+                          (minimum-distance . 0)
+                          (padding . 1))
+  top-markup-spacing = #'((basic-distance . 0)
+                          (minimum-distance . 0)
+                          (padding . 1))
+  last-bottom-spacing = #'((basic-distance . 1)
+                           (minimum-distance . 0)
+                           (padding . 1)
+                           (stretchability . 30))
 
 
   %%