Make format for key changes consistent; minor formatting corrections for affected regtests

Following my NR updates, David identified other places where there is no space between the key signature and the \major or \minor.  It's not an error, but it is inconsistent, so this addresses the inconsistency.  It also fixes the formatting on some of the affected regression tests.  Passes make doc and make test.

[PhilEHolmes, 2013-07-02 10:33:09]

Please review

[Trevor Daniels, 2013-07-02 11:49:47]

LGTM with one minor suggestion

https://codereview.appspot.com/10868043/diff/1/input/regression/tuplet-full-l...
File input/regression/tuplet-full-length.ly (right):

https://codereview.appspot.com/10868043/diff/1/input/regression/tuplet-full-l...
input/regression/tuplet-full-length.ly:11: indent = 0.0
Even better: drop ragged-right down to next line too

[dak, 2013-07-02 12:07:19]

https://codereview.appspot.com/10868043/diff/1/Documentation/changes.tely
File Documentation/changes.tely (right):

https://codereview.appspot.com/10868043/diff/1/Documentation/changes.tely#new...
Documentation/changes.tely:320: \clef bass \key es \major es g bes d
Ok, here is a true "can of worms" followup item: in the case where the \key
statement is followed by more material on the same line, it would make sense to
have a _double_ space before the following material.

git grep '\\key [a-z]\+ \\[a-z]\+ [^ {}]'

throws out a whole lot of candidates for that.  We don't do this sort of double
spacing with other constructs, but in the case of \major I find the resulting
progression in the line badly readable.

The previous e\major worked against this visually.  Cramming this together might
not be the prettiest thing but it was effective.

If we don't do this, then it might make sense as a sort of rule to separate
complete music function calls on a line with double space.

Which would mean

\clef bass  \key es \major  es g bes d

in this case.  Now that would be actually a pretty large undertaking to do in
general (though I'd consider it helpful).  But in case of \key, we might
actually want this now in order to avoid people parsing this as "\key es"
"\major es" "g bes d": since the \key statement ends in a backslashed word, the
danger for misparsing is here particularly large.  Of course, if one writes

\clef treble \bar "||" \key es \major  es g bes d

then there is a certain temptation to do

\clef treble  \bar "||"  \key es \major  es g bes d

right away.  But I think that \key is the worst offender here, and since it gets
worse by this patch, it might seem reasonable to tackle just that right now.

[mail_philholmes.net, 2013-07-02 13:26:00]

----- Original Message ----- 
From: <dak@gnu.org>
To: <PhilEHolmes@googlemail.com>; <tdanielsmusic@googlemail.com>
Cc: <reply@codereview-hr.appspotmail.com>; <lilypond-devel@gnu.org>
Sent: Tuesday, July 02, 2013 1:07 PM
Subject: Re: Make format for key changes consistent; minor 
formattingcorrections for affected regtests (issue 10868043)


>
> https://codereview.appspot.com/10868043/diff/1/Documentation/changes.tely
> File Documentation/changes.tely (right):
>
>
https://codereview.appspot.com/10868043/diff/1/Documentation/changes.tely#new...
> Documentation/changes.tely:320: \clef bass \key es \major es g bes d
> Ok, here is a true "can of worms" followup item: in the case where the
> \key statement is followed by more material on the same line, it would
> make sense to have a _double_ space before the following material.
>
> git grep '\\key [a-z]\+ \\[a-z]\+ [^ {}]'
>
> throws out a whole lot of candidates for that.  We don't do this sort of
> double spacing with other constructs, but in the case of \major I find
> the resulting progression in the line badly readable.

That's a whole new deal - related to this update, granted, but a separate 
issue really.  It's rather proposing a new documentation on the back of an 
agreed update.  Could I suggest we do the update, and if you still want a 
double space after key changes, you either propose it in devel, or put up 
your own patch for comment, once this is pushed?

--
Phil Holmes 

[Keith, 2013-07-02 16:15:51]

LGTM

You could also be consistent the other way, closing the space in the key
designation.   I wrote a couple of the ones that were inconsistently closed.  I
was thinking that the tonic and mode are as closely related as a note and its
duration.
  \key b\minor 
  b2\marcato-\sf

[t.daniels_treda.co.uk, 2013-07-02 18:59:38]

dak@gnu.org wrote Tuesday, July 02, 2013 1:07 PM

> Ok, here is a true "can of worms" followup item: in the case where the
> \key statement is followed by more material on the same line, it would
> make sense to have a _double_ space before the following material.
> 
> git grep '\\key [a-z]\+ \\[a-z]\+ [^ {}]'
> 
> throws out a whole lot of candidates for that.  We don't do this sort of
> double spacing with other constructs, but in the case of \major I find
> the resulting progression in the line badly readable.

I agree the legibility of this example is bad, but rather than introducing
a double space I think I'd prefer to see any material following

\clef bass \key es \major

moved to a new line.  If the material contains notes, as it does in the
quoted example, then that would be definitely be my preference.

But as Phil suggests, this should be the subject of a new issue.

Trevor

[email_philholmes.net, 2013-07-03 16:14:33]

----- Original Message ----- 
From: "Trevor Daniels" <t.daniels@treda.co.uk>
To: <PhilEHolmes@googlemail.com>; <tdanielsmusic@googlemail.com>; 
<dak@gnu.org>; <lilypond-devel@gnu.org>; 
<reply@codereview-hr.appspotmail.com>
Sent: Tuesday, July 02, 2013 7:59 PM
Subject: Re: Make format for key changes consistent; minor formatting 
corrections for affected regtests (issue 10868043)


>
> dak@gnu.org wrote Tuesday, July 02, 2013 1:07 PM
>
>> Ok, here is a true "can of worms" followup item: in the case where the
>> \key statement is followed by more material on the same line, it would
>> make sense to have a _double_ space before the following material.
>>
>> git grep '\\key [a-z]\+ \\[a-z]\+ [^ {}]'
>>
>> throws out a whole lot of candidates for that.  We don't do this sort of
>> double spacing with other constructs, but in the case of \major I find
>> the resulting progression in the line badly readable.
>
> I agree the legibility of this example is bad, but rather than introducing
> a double space I think I'd prefer to see any material following
>
> \clef bass \key es \major
>
> moved to a new line.  If the material contains notes, as it does in the
> quoted example, then that would be definitely be my preference.
>
> But as Phil suggests, this should be the subject of a new issue.
>
> Trevor

I agree with and prefer the new line concept - that's certainly what I do. 
It would require an update to the style manual in the CG.  We could consider 
broadening it to other divisions that should be on separate lines.

--
Phil Holmes