On 2010/12/11 16:33:48, pkx166h wrote:
I hope this is the right method to have a discussion on Rietveld, I
have added
my own comments/responses to yours inline.
Yes, this is a very good way to do it. You can also just add a comment in the patchset. http://codereview.appspot.com/3581041/diff/1/Documentation/notation/repeats.itely#newcode150
Documentation/notation/repeats.itely:150: @rprogram{An extra staff
appears}. Do
not place bar checks outside On 2010/12/11 00:36:29, Carl wrote: > I think this is awkward. > > I think it would be better to do the following: > > 1) Put barchecks inside the alternatives in the example.
I know that we were trying to avoid bar checks on single measures -
this was/is
CG policy
But this isn't a single measure. There are three measures in the example. Bar checks *should* be used here, although they're not required.
and bar checks are not mandatory anyway (helpful but not a requirement) so add nothing to an example other than this one case. If
I put
them here, then I have to put them throughout the other examples.
In my opinion, we should be moving toward bar checks in examples where it is helpful, rather than as a mindless policy requiring consistency in all cases. This particular case is a case where a user made a mistake by copying an example and doing what he thought was right. If the bar check were inside the alternative, the mistake would not have been made. So I think it's a positive change.
I take the point that you might think it better to show an example which I could
for
instance with an @example but I'd like some opinion on that because we
could
then start setting precedence on showing what NOT to do if you see
what I mean? To me the precedent is set by virtue of the fact that a user made the mistake. I agree we don't want to show what not to do in general. We could probably have avoided the problem if the bar check were just in the alternatives. http://codereview.appspot.com/3581041/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel