NR: Removed example for alternate repeats

NR: Removed example for alternate repeats

Since Issue 3855 it is no longer necessary to set the
timing.Measurelength when alternates begin with
incomplete measures.

[pkx166h, 2014-02-09 21:58:29]

Added examples (also used in Changes.tely) and some index entries

[Keith, 2014-02-10 06:42:20]

I suggest just removing the obsolete text, and skipping the additions (unless
you are worried that the manual is getting too short).

https://codereview.appspot.com/61170044/diff/20001/Documentation/notation/rep...
File Documentation/notation/repeats.itely (left):

https://codereview.appspot.com/61170044/diff/20001/Documentation/notation/rep...
Documentation/notation/repeats.itely:172: @lilypond[verbatim,quote,relative=1]
While you are looking at this section, you might consider removing the comments
in these two examples.

The comments "no \partial here" make it very difficult to read.  I look at it
and keep thinking that we *do* need a \partial somewhere because I see it in
several places.  

If this example didn't exist I would not think I needed \partial to write this. 
Simple examples confirming that fact would help everyone.

https://codereview.appspot.com/61170044/diff/20001/Documentation/notation/rep...
File Documentation/notation/repeats.itely (right):

https://codereview.appspot.com/61170044/diff/20001/Documentation/notation/rep...
Documentation/notation/repeats.itely:215: 
These three examples are more useful as regression tests than as documentation.

If someone needs a time-signature change in the first alternative, this is the
only way to write it.  So the one or two people who will write something like
this don't need the docs, and the rest of us will spend time being puzzled
before figuring out that the second ending in 3/4 time is how it must work.

[pkx166h, 2014-02-10 12:31:25]

On 2014/02/10 06:42:20, Keith wrote:
> I suggest just removing the obsolete text, and skipping the additions (unless
> you are worried that the manual is getting too short).

:)

Actually I think I had a conversation on similar lines with The Grand 'Foobar'
himself (HRH Graham P), when I started. As far as the LM goes, yes I take that
point about there probably being a 'too large' moment, but for the NR, I've
never seen it as an issue. It's a reference, something to jump in and out of for
whatever 'command' or 'function' you need for a particular job. For me a
reference, as long as it is current and doesn't repeat information in multiple
places, can never be too big.

Anyway, I take the point of your comment. That last paragraph was just my own
philosophical POV.

I'll remove the additions - as we have them in change.tely (with examples) so if
someone does have some piece that they re-run with 2.19.x and greater that
suddenly gives them a timing error or odd chord change then at least when the
behaviour changed has been documented.


> 
>
https://codereview.appspot.com/61170044/diff/20001/Documentation/notation/rep...
> File Documentation/notation/repeats.itely (left):
> 
>
https://codereview.appspot.com/61170044/diff/20001/Documentation/notation/rep...
> Documentation/notation/repeats.itely:172: @lilypond[verbatim,quote,relative=1]
> While you are looking at this section, you might consider removing the
comments
> in these two examples.

...

Sure, but I'll make a new patch (and tracker) for these suggestions

...

> 
>
https://codereview.appspot.com/61170044/diff/20001/Documentation/notation/rep...
> Documentation/notation/repeats.itely:215: 
> These three examples are more useful as regression tests than as
documentation.
> 
> If someone needs a time-signature change in the first alternative, this is the
> only way to write it.  So the one or two people who will write something like
> this don't need the docs, and the rest of us will spend time being puzzled
> before figuring out that the second ending in 3/4 time is how it must work.

Are they robust enough? Do they exercise each property properly? I don't know if
I am really educated enough in the code to comment. For example should they have
2, 3 or 4 alternatives instead of just the 1?

I also seem to recall a dev conversation that said we had 'too many' regression
tests as well :)

http://lists.gnu.org/archive/html/lilypond-devel/2014-01/msg00050.html

(perhaps taken out of context?).

For now I won't make reg test *.ly files, unless there is an obvious consensus
that these are OK as is, in which case we need a new tracker again to keep it
all easy to review rather than mix lots of disparate items in a single patch.

Thanks for the review Keith.

James

[pkx166h, 2014-02-10 12:40:19]

Removed examples based on Keith's suggestions (kept in @file reference in the
@seealso section)

[Keith, 2014-02-10 17:12:25]

On Mon, 10 Feb 2014 04:31:25 -0800, <pkx166h@gmail.com> wrote:

>> These three examples are more useful as regression tests than as
>> documentation.

> Are they robust enough? Do they exercise each property properly?

They seem good enough, but it is not essential to add them to
/input/regressoin/
They won't get lost, being findable in the mailing list archives, and there is
tracker issue 3841 to remind us to get the newly-working behavior into
regression tests eventually.