Re: Doc: NR added @knownissue for beam properties (issue 5504100)

[pkx166h]

See comments below, thanks.


http://codereview.appspot.com/5504100/diff/1/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):

http://codereview.appspot.com/5504100/diff/1/Documentation/notation/rhythms.itely#newcode1953
Documentation/notation/rhythms.itely:1953: @knownissues
On 2012/01/01 01:55:11, Carl wrote:
> I wonder if it would be better to actually include a snippet, instead
of just a
> known issue.

See comment below

http://codereview.appspot.com/5504100/diff/1/Documentation/notation/rhythms.itely#newcode1954
Documentation/notation/rhythms.itely:1954: The properties of a beam are
determined at the @emph{start} of its
On 2012/01/01 02:59:06, Keith wrote:
> I had no idea what this was about until going back to the tracker
issue.  The
> surprising bit is with automatic beams, because you don't see where
they start,
> so we need an example.  You might just say :
> "If you change properties of beam when a beam has already started,
that beam
> will not be affected.  For example, with the input {\hideNotes c8 f8
> \unHideNotes c8 f8} the \hideNotes makes transparent the single
automatic beam
> across all four notes.  If you want the beam to be visible for the
last two
> notes you need to specify it explicitly. {\hideNotes c8 f8
\unHideNotes c8[ f8]}
> "
> This one is more a warning than a knownissue.

Happy with @warning vs @knownissues

http://codereview.appspot.com/5504100/diff/1/Documentation/notation/rhythms.itely#newcode1954
Documentation/notation/rhythms.itely:1954: The properties of a beam are
determined at the @emph{start} of its
On 2012/01/01 03:08:19, Carl wrote:
> On 2012/01/01 02:59:06, Keith wrote:
> > I had no idea what this was about until going back to the tracker
issue.  The
> > surprising bit is with automatic beams, because you don't see where
they
> start,
> > so we need an example.  You might just say :
> > "If you change properties of beam when a beam has already started,
that beam
> > will not be affected.  For example, with the input {\hideNotes c8 f8
> > \unHideNotes c8 f8} the \hideNotes makes transparent the single
automatic beam
> > across all four notes.  If you want the beam to be visible for the
last two
> > notes you need to specify it explicitly. {\hideNotes c8 f8
\unHideNotes c8[
> f8]}

> This is why I recommend a snippet, rather than just the text.  If we
need to
> show a LilyPond example, we should show it with the output, rather
than just
> describing it in the text.

I disagree.

The example in the tracker is overly complicated for what (I still
maintain) is easily explained. However *if* we really do need an example
then the \hideNotes one is not ideal. I struggled myself with that one
in the tracker, it isn't a 'tiny example' by any stretch of the
imagination and I knew perfectly well what was meant by the problem only
*after* I read the text explanation, the picture on the tracker added
nothing for me.

http://codereview.appspot.com/5504100/diff/1/Documentation/notation/rhythms.itely#newcode1956
Documentation/notation/rhythms.itely:1956: the beam has been completed
will not take effect until the @emph{next},
On 2012/01/01 01:55:11, Carl wrote:
> I think it would be better to eliminate the , and the word "new", but
I don't
> feel really strongly about it.

No problem with that.

http://codereview.appspot.com/5504100/