Issue 12724043: Adds bar line section to LM (Issue 3408) (Closed)
|
Created:
10 years, 8 months ago by PhilEHolmes Modified:
10 years, 8 months ago CC:
lilypond-devel_gnu.org Visibility:
Public. |
DescriptionAdds bar line section to LM (Issue 3408)
Patch Set 1 #
Total comments: 3
MessagesTotal messages: 17
Please review.
Sign in to reply to this message.
Non-standard headings; otherwise LGTM. https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-... File Documentation/learning/common-notation.itely (right): https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-... Documentation/learning/common-notation.itely:67: @subheading Bar lines @unnumberedsubsubsec plus @node and menu See http://www.lilypond.org/doc/v2.17/Documentation/contributor/sectioning-commands https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-... Documentation/learning/common-notation.itely:80: @subheading Bar checks ditto
Sign in to reply to this message.
----- Original Message ----- From: <tdanielsmusic@googlemail.com> To: <PhilEHolmes@googlemail.com> Cc: <lilypond-devel@gnu.org>; <reply@codereview-hr.appspotmail.com> Sent: Sunday, August 11, 2013 3:33 PM Subject: Re: Adds bar line section to LM (Issue 3408) (issue 12724043) > Non-standard headings; otherwise LGTM. > > > https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-... > File Documentation/learning/common-notation.itely (right): > > https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-... > Documentation/learning/common-notation.itely:67: @subheading Bar lines > @unnumberedsubsubsec > plus @node and menu > See > http://www.lilypond.org/doc/v2.17/Documentation/contributor/sectioning-commands > > https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-... > Documentation/learning/common-notation.itely:80: @subheading Bar checks > ditto > > https://codereview.appspot.com/12724043/ More than happy to make this change, but there's lots and lots of subheading headings in that file - should they all be taken out? -- Phil Holmes
Sign in to reply to this message.
On 2013/08/12 13:48:32, email_philholmes.net wrote: > ----- Original Message ----- > From: <mailto:tdanielsmusic@googlemail.com> > To: <mailto:PhilEHolmes@googlemail.com> > Cc: <lilypond-devel@gnu.org>; <mailto:reply@codereview-hr.appspotmail.com> > Sent: Sunday, August 11, 2013 3:33 PM > Subject: Re: Adds bar line section to LM (Issue 3408) (issue 12724043) > > > > Non-standard headings; otherwise LGTM. > > > > > > > https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-... > > File Documentation/learning/common-notation.itely (right): > > > > > https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-... > > Documentation/learning/common-notation.itely:67: @subheading Bar lines > > @unnumberedsubsubsec > > plus @node and menu > > See > > > http://www.lilypond.org/doc/v2.17/Documentation/contributor/sectioning-commands > > > > > https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-... > > Documentation/learning/common-notation.itely:80: @subheading Bar checks > > ditto > > > > https://codereview.appspot.com/12724043/ > > More than happy to make this change, but there's lots and lots of subheading > headings in that file - should they all be taken out? > > -- > Phil Holmes > Well, it's quite a bit of work as they'll need menus and nodes adding. Each subsubsec will be rather small, but I think it is well worth doing as these subsubsecs can then be referenced individually and they'll appear as headings in the ToC. They can also be given a more direct reference from the indexes.
Sign in to reply to this message.
----- Original Message ----- From: <tdanielsmusic@googlemail.com> To: <PhilEHolmes@googlemail.com>; <email@philholmes.net> Cc: <reply@codereview-hr.appspotmail.com>; <lilypond-devel@gnu.org> Sent: Monday, August 12, 2013 3:50 PM Subject: Re: Adds bar line section to LM (Issue 3408) (issue 12724043) > On 2013/08/12 13:48:32, email_philholmes.net wrote: >> ----- Original Message ----- >> From: <mailto:tdanielsmusic@googlemail.com> >> To: <mailto:PhilEHolmes@googlemail.com> >> Cc: <lilypond-devel@gnu.org>; > <mailto:reply@codereview-hr.appspotmail.com> >> Sent: Sunday, August 11, 2013 3:33 PM >> Subject: Re: Adds bar line section to LM (Issue 3408) (issue 12724043) > > >> > Non-standard headings; otherwise LGTM. >> > >> > >> > > > https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-... >> > File Documentation/learning/common-notation.itely (right): >> > >> > > > https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-... >> > Documentation/learning/common-notation.itely:67: @subheading Bar > lines >> > @unnumberedsubsubsec >> > plus @node and menu >> > See >> > > > http://www.lilypond.org/doc/v2.17/Documentation/contributor/sectioning-commands >> > >> > > > https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-... >> > Documentation/learning/common-notation.itely:80: @subheading Bar > checks >> > ditto >> > >> > https://codereview.appspot.com/12724043/ > >> More than happy to make this change, but there's lots and lots of > subheading >> headings in that file - should they all be taken out? > >> -- >> Phil Holmes > > > Well, it's quite a bit of work as they'll need menus and nodes > adding. Each subsubsec will be rather small, but I think it is > well worth doing as these subsubsecs can then be referenced > individually and they'll appear as headings in the ToC. They > can also be given a more direct reference from the indexes. > > https://codereview.appspot.com/12724043/ > OK - I suggest I don't change my patch as you've suggested, because the way I did it was to copy the original, and so it currently follows the style for that section. I'll raised an issue to change all instances of @subheading to @unnumberedsubsubsec in the LM and do that once this patch is pushed. That sound OK? -- Phil Holmes
Sign in to reply to this message.
Phil, you wrote > OK - I suggest I don't change my patch as you've suggested, because the way > I did it was to copy the original, and so it currently follows the style for > that section. I'll raised an issue to change all instances of @subheading > to @unnumberedsubsubsec in the LM and do that once this patch is pushed. > That sound OK? Yup. Trevor
Sign in to reply to this message.
The content LGTM.
Sign in to reply to this message.
https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-... File Documentation/learning/common-notation.itely (right): https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-... Documentation/learning/common-notation.itely:64: @node Bar lines and bar checks Do we really need to explain how to do special bar lines before explaining accidentals? The only reason we have bar checks here is that it helps the reader to see the | symbols in the input. I don't think it's useful to explain special bar lines here. Can't people find special bar lines in Notation?
Sign in to reply to this message.
----- Original Message ----- From: <graham@percival-music.ca> To: <PhilEHolmes@googlemail.com>; <tdanielsmusic@googlemail.com>; <email@philholmes.net>; <mail@philholmes.net>; <t.daniels@treda.co.uk>; <janek.lilypond@gmail.com> Cc: <lilypond-devel@gnu.org>; <reply@codereview-hr.appspotmail.com> Sent: Friday, August 16, 2013 5:48 AM Subject: Re: Adds bar line section to LM (Issue 3408) (issue 12724043) > > https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-... > File Documentation/learning/common-notation.itely (right): > > https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-... > Documentation/learning/common-notation.itely:64: @node Bar lines and bar > checks > Do we really need to explain how to do special bar lines before > explaining accidentals? According to mail to -user, yes. The only reason I did this was because of a request there. > The only reason we have bar checks here is that it helps the reader to > see the | symbols in the input. I don't think it's useful to explain > special bar lines here. Can't people find special bar lines in > Notation? > > https://codereview.appspot.com/12724043/ > -- Phil Holmes
Sign in to reply to this message.
On 2013/08/16 08:16:22, mail_philholmes.net wrote: > > Do we really need to explain how to do special bar lines before > > explaining accidentals? > > According to mail to -user, yes. The only reason I did this was because of > a request there. The mail said it seemed strange that there was final bar-line in any examples in the Learning Manual. I would be tempted to simply insert \bar "|." into the longer examples in the LM, with no explanation, so it is there for curious people to find, and shows them what to look up in the index to learn more. I see how a digression on to \bar might be distracting here. For at least one person, confusion about how to indicate the end of a piece was also distracting.
Sign in to reply to this message.
On Fri, Aug 16, 2013 at 08:53:44AM +0000, k-ohara5a5a@oco.net wrote: > On 2013/08/16 08:16:22, mail_philholmes.net wrote: > >> Do we really need to explain how to do special bar lines before > >> explaining accidentals? > > >According to mail to -user, yes. The only reason I did this was > because of > >a request there. > > The mail said it seemed strange that there was final bar-line in any > examples in the Learning Manual. I don't think we need to respond to every single doc suggestion; often users are unaware of the trade-offs we've chosen or are particularly focused on their application domain ("why bother with stuff for singers? the LM should only be about monophonic music which is used for strings"). > I would be tempted to simply insert \bar "|." into the longer examples > in the LM, with no explanation, so it is there for curious people to > find, and shows them what to look up in the index to learn more. Either that, or add "alternate bar lines" to 2.4 Final touches. - Graham
Sign in to reply to this message.
----- Original Message ----- From: "Graham Percival" <graham@percival-music.ca> To: <PhilEHolmes@googlemail.com>; <tdanielsmusic@googlemail.com>; <email@philholmes.net>; <mail@philholmes.net>; <t.daniels@treda.co.uk>; <janek.lilypond@gmail.com>; <k-ohara5a5a@oco.net>; <lilypond-devel@gnu.org>; <reply@codereview-hr.appspotmail.com> Sent: Friday, August 16, 2013 9:59 AM Subject: Re: Adds bar line section to LM (Issue 3408) (issue 12724043) > On Fri, Aug 16, 2013 at 08:53:44AM +0000, k-ohara5a5a@oco.net wrote: >> On 2013/08/16 08:16:22, mail_philholmes.net wrote: >> >> Do we really need to explain how to do special bar lines before >> >> explaining accidentals? >> >> >According to mail to -user, yes. The only reason I did this was >> because of >> >a request there. >> >> The mail said it seemed strange that there was final bar-line in any >> examples in the Learning Manual. > > I don't think we need to respond to every single doc suggestion; > often users are unaware of the trade-offs we've chosen or are > particularly focused on their application domain ("why bother with > stuff for singers? the LM should only be about monophonic music > which is used for strings"). > >> I would be tempted to simply insert \bar "|." into the longer examples >> in the LM, with no explanation, so it is there for curious people to >> find, and shows them what to look up in the index to learn more. > > Either that, or add "alternate bar lines" to 2.4 Final touches. > > - Graham I actually proposed adding a short section in 2.1.1 on July 6th and nobody demurred, which is why I went ahead and did it. The section I've added also clarifies how bar lines are created and the difference from bar checks, which confuses no end of people. And yes, I do think that bars should come before accidentals. -- Phil Holmes
Sign in to reply to this message.
On 2013/08/16 08:59:36, Graham Percival wrote: > On Fri, Aug 16, 2013 at 08:53:44AM +0000, mailto:k-ohara5a5a@oco.net wrote: > > On 2013/08/16 08:16:22, http://mail_philholmes.net wrote: > > >> Do we really need to explain how to do special bar lines before > > >> explaining accidentals? > > > > >According to mail to -user, yes. The only reason I did this was > > because of > > >a request there. > > > > The mail said it seemed strange that there was final bar-line in any > > examples in the Learning Manual. > > I don't think we need to respond to every single doc suggestion; > often users are unaware of the trade-offs we've chosen or are > particularly focused on their application domain ("why bother with > stuff for singers? the LM should only be about monophonic music > which is used for strings"). You make a good point about trade-offs. However, i think that adding this short explanation would be inappropriate. cheers, Janek
Sign in to reply to this message.
On Fri, Aug 16, 2013 at 02:32:35PM +0100, Phil Holmes wrote: > >On Fri, Aug 16, 2013 at 08:53:44AM +0000, k-ohara5a5a@oco.net wrote: > >>I would be tempted to simply insert \bar "|." into the longer examples > >>in the LM, with no explanation, so it is there for curious people to > >>find, and shows them what to look up in the index to learn more. > > > >Either that, or add "alternate bar lines" to 2.4 Final touches. > > I actually proposed adding a short section in 2.1.1 on July 6th and > nobody demurred, which is why I went ahead and did it. Sorry, I only look at the countdown emails... and the only reason for that is to try to encourage other "mostly-ex project members" to do the same. > The section I've added also clarifies how bar lines are created > and the difference from bar checks, which confuses no end of > people. And yes, I do think that bars should come before > accidentals. Could I tempt you by suggesting a sentence like "Special types of bar lines can be created with other methods, covered in @ref{whatever}" ? that could either link to Notation, or else to a later section of Learning which explains these. Ultimately this is just a suggestion; I don't feel that I have the authority to insist on anything at this point. I've given my feedback; do what you think is best. Cheers, - Graham
Sign in to reply to this message.
2013/8/17 <janek.lilypond@gmail.com>: > On 2013/08/16 08:59:36, Graham Percival wrote: >> I don't think we need to respond to every single doc suggestion; >> often users are unaware of the trade-offs we've chosen or are >> particularly focused on their application domain ("why bother with >> stuff for singers? the LM should only be about monophonic music >> which is used for strings"). > > You make a good point about trade-offs. However, i think that adding > this short explanation would be inappropriate. Oops, typo. I intended to write "wouldn't be inapproriate". Sorry for confusion. Janek
Sign in to reply to this message.
2013/8/18 Graham Percival <graham@percival-music.ca>: > On Fri, Aug 16, 2013 at 02:32:35PM +0100, Phil Holmes wrote: >> >On Fri, Aug 16, 2013 at 08:53:44AM +0000, k-ohara5a5a@oco.net wrote: >> >>I would be tempted to simply insert \bar "|." into the longer examples >> >>in the LM, with no explanation, so it is there for curious people to >> >>find, and shows them what to look up in the index to learn more. >> > >> >Either that, or add "alternate bar lines" to 2.4 Final touches. >> >> I actually proposed adding a short section in 2.1.1 on July 6th and >> nobody demurred, which is why I went ahead and did it. > > Sorry, I only look at the countdown emails... and the only reason > for that is to try to encourage other "mostly-ex project members" > to do the same. Not that i'm much of an ex-member (hopefully), but it's working in my case: i am motivated by you to do patch reviews, Graham! :) cheers, Janek
Sign in to reply to this message.
----- Original Message ----- From: "Graham Percival" <graham@percival-music.ca> To: "Phil Holmes" <email@philholmes.net> Cc: <PhilEHolmes@googlemail.com>; <tdanielsmusic@googlemail.com>; <t.daniels@treda.co.uk>; <janek.lilypond@gmail.com>; <k-ohara5a5a@oco.net>; <lilypond-devel@gnu.org>; <reply@codereview-hr.appspotmail.com> Sent: Sunday, August 18, 2013 10:46 AM Subject: Re: Adds bar line section to LM (Issue 3408) (issue 12724043) > On Fri, Aug 16, 2013 at 02:32:35PM +0100, Phil Holmes wrote: >> >On Fri, Aug 16, 2013 at 08:53:44AM +0000, k-ohara5a5a@oco.net wrote: >> >>I would be tempted to simply insert \bar "|." into the longer examples >> >>in the LM, with no explanation, so it is there for curious people to >> >>find, and shows them what to look up in the index to learn more. >> > >> >Either that, or add "alternate bar lines" to 2.4 Final touches. >> >> I actually proposed adding a short section in 2.1.1 on July 6th and >> nobody demurred, which is why I went ahead and did it. > > Sorry, I only look at the countdown emails... and the only reason > for that is to try to encourage other "mostly-ex project members" > to do the same. > >> The section I've added also clarifies how bar lines are created >> and the difference from bar checks, which confuses no end of >> people. And yes, I do think that bars should come before >> accidentals. > > Could I tempt you by suggesting a sentence like "Special types of > bar lines can be created with other methods, covered in > @ref{whatever}" ? that could either link to Notation, or else to > a later section of Learning which explains these. > > Ultimately this is just a suggestion; I don't feel that I have the > authority to insist on anything at this point. I've given my > feedback; do what you think is best. > > Cheers, > - Graham > It was counted down and pushed, so making further changes would be a further patch. As I said, I think the opportunity to describe bar lines versus bar checks here has some value in its own right. Had I not already pushed the existing patch, I would have used your suggestion as well as that, deleting my "special bar lines" bit. But considering water->bridge, it's probably not worth further effort. -- Phil Holmes
Sign in to reply to this message.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
