Re: NR: Removed example for alternate repeats (issue 61170044)

[pkx166h]

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/repeats.itely
> File Documentation/notation/repeats.itely (left):


https://codereview.appspot.com/61170044/diff/20001/Documentation/notation/repeats.itely#oldcode172
> 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/repeats.itely#newcode215
> 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

https://codereview.appspot.com/61170044/