[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.
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

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
instance with an @example but I'd like some opinion on that because we
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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]