[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Doc: Various to LM and NR from user email threads (issue3581041)
From: |
Carl . D . Sorensen |
Subject: |
Re: Doc: Various to LM and NR from user email threads (issue3581041) |
Date: |
Sat, 11 Dec 2010 16:57:48 +0000 |
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/
- Re: Doc: Various to LM and NR from user email threads (issue3581041), percival . music . ca, 2010/12/11
- Re: Doc: Various to LM and NR from user email threads (issue3581041), pkx166h, 2010/12/11
- Re: Doc: Various to LM and NR from user email threads (issue3581041),
Carl . D . Sorensen <=
- Re: Doc: Various to LM and NR from user email threads (issue3581041), v . villenave, 2010/12/11
- Re: Doc: Various to LM and NR from user email threads (issue3581041), pkx166h, 2010/12/11
- Re: Doc: Various to LM and NR from user email threads (issue3581041), n . puttock, 2010/12/11
- Re: Doc: Various to LM and NR from user email threads (issue3581041), percival . music . ca, 2010/12/12
- Re: Doc: Various to LM and NR from user email threads (issue3581041), pkx166h, 2010/12/12
- Re: Doc: Various to LM and NR from user email threads (issue3581041), pkx166h, 2010/12/14
- Re: Doc: Various to LM and NR from user email threads (issue3581041), tdanielsmusic, 2010/12/14
- Re: Doc: Various to LM and NR from user email threads (issue3581041), percival . music . ca, 2010/12/14