Code review - Issue 343060043: Clarify notation for slurs and beamshttps://codereview.appspot.com/2018-05-02T23:13:54+00:00rietveld
Message from unknown
2018-04-29T23:05:38+00:00Carlurn:md5:0276f7e93780cc229c6f47685a074391
Message from torsten.haemmerle@web.de
2018-04-30T11:37:09+00:00Be-3urn:md5:5a95e7c69a9ee3682240b3f075c87660
Hi Carl,
Concise, comprehensible, - LGTM!
Perhaps it should be explicitly pointed out that the duration shorthand does not work for rests.
There have been some misconceptions lately on the user list, and so I think this detail probably deserves special attendance.
Thanks,
Torsten
https://codereview.appspot.com/343060043/diff/1/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (right):
https://codereview.appspot.com/343060043/diff/1/Documentation/learning/fundamental.itely#newcode487
Documentation/learning/fundamental.itely:487: \absolute {c'8-1--(~^\markup{"text annotationi"} c' d')}
Shouldn't it be "text annotation"?
Message from tdanielsmusic@googlemail.com
2018-04-30T12:08:20+00:00Trevor Danielsurn:md5:6c2019220554dc89f1aa79669bc996d4
Hi Carl
LGTM, with a couple of minor comments.
Trevor
https://codereview.appspot.com/343060043/diff/1/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (right):
https://codereview.appspot.com/343060043/diff/1/Documentation/learning/fundamental.itely#newcode488
Documentation/learning/fundamental.itely:488: @end lilypond
I'd prefer \relative or nothing in this example. \absolute
has not been introduced earlier, in fact it's not used at
all in the LM.
https://codereview.appspot.com/343060043/diff/1/Documentation/learning/fundamental.itely#newcode492
Documentation/learning/fundamental.itely:492: @ruser{Expressive marks},
Might be good to point to the relevant sections in the LM
as well, in Section 2.1
Message from Carl.D.Sorensen@gmail.com
2018-04-30T14:56:48+00:00Carlurn:md5:cf877fed31b3231442c474166b37cd72
On 2018/04/30 11:37:09, Be-3 wrote:
> Hi Carl,
>
> Concise, comprehensible, - LGTM!
>
> Perhaps it should be explicitly pointed out that the duration shorthand does not
> work for rests.
> There have been some misconceptions lately on the user list, and so I think this
> detail probably deserves special attendance.
I've added a sentence that should clarify.
> https://codereview.appspot.com/343060043/diff/1/Documentation/learning/fundamental.itely#newcode487
> Documentation/learning/fundamental.itely:487: \absolute {c'8-1--(~^\markup{"text
> annotationi"} c' d')}
> Shouldn't it be "text annotation"?
Yes. Now you know which editor I was using to create the patch -- it's vim leftovers.
Thanks for the catch.
Message from Carl.D.Sorensen@gmail.com
2018-04-30T15:03:35+00:00Carlurn:md5:31f0828fc02eba6573f529c43c98f1b3
On 2018/04/30 12:08:20, Trevor Daniels wrote:
>
> https://codereview.appspot.com/343060043/diff/1/Documentation/learning/fundamental.itely#newcode488
> Documentation/learning/fundamental.itely:488: @end lilypond
> I'd prefer \relative or nothing in this example. \absolute
> has not been introduced earlier, in fact it's not used at
> all in the LM.
Good idea. I went with nothing.
>
> https://codereview.appspot.com/343060043/diff/1/Documentation/learning/fundamental.itely#newcode492
> Documentation/learning/fundamental.itely:492: @ruser{Expressive marks},
> Might be good to point to the relevant sections in the LM
> as well, in Section 2.1
Also a good idea. I've added the references.
Thanks,
Carl
Message from unknown
2018-04-30T15:28:24+00:00Carlurn:md5:4c457dcd936424fe2d3db272fad7b1a8
Message from Carl.D.Sorensen@gmail.com
2018-04-30T15:28:25+00:00Carlurn:md5:5ddb7288f914dd66699d1a1339c2cc57
Respond to Trevor and Torsten
Message from tdanielsmusic@googlemail.com
2018-04-30T15:47:26+00:00Trevor Danielsurn:md5:47cba409fa42fc0cc5c65512dfcfdc0d
Hi Carl
Another minor nit! Otherwise looks fine.
Trevor
https://codereview.appspot.com/343060043/diff/20001/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (right):
https://codereview.appspot.com/343060043/diff/20001/Documentation/learning/fundamental.itely#newcode495
Documentation/learning/fundamental.itely:495: @rlearning{Adding text}.
Not sure if it makes any difference but we usually use
@ref for references within the same manual.
Message from Carl.D.Sorensen@gmail.com
2018-04-30T15:51:16+00:00Carlurn:md5:5b4211e1258ad1ccd08ed6004cb7ec75
Thanks for the feedback, Trevor.
https://codereview.appspot.com/343060043/diff/20001/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (right):
https://codereview.appspot.com/343060043/diff/20001/Documentation/learning/fundamental.itely#newcode495
Documentation/learning/fundamental.itely:495: @rlearning{Adding text}.
On 2018/04/30 15:47:26, Trevor Daniels wrote:
> Not sure if it makes any difference but we usually use
> @ref for references within the same manual.
Fundamentals is in a different source file than common notation. If I use @ref, it breaks the info build. So I had to use @rlearning to get it to pass make doc.
If I'm doing something wrong, and there's some way to get @ref to work, I'd be happy to know about it.
Message from tdanielsmusic@googlemail.com
2018-04-30T17:04:02+00:00Trevor Danielsurn:md5:7d02f5ae287f8fe3432c2c5a3feccb0e
https://codereview.appspot.com/343060043/diff/20001/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (right):
https://codereview.appspot.com/343060043/diff/20001/Documentation/learning/fundamental.itely#newcode495
Documentation/learning/fundamental.itely:495: @rlearning{Adding text}.
On 2018/04/30 15:51:16, Carl wrote:
> On 2018/04/30 15:47:26, Trevor Daniels wrote:
> > Not sure if it makes any difference but we usually use
> > @ref for references within the same manual.
>
> Fundamentals is in a different source file than common notation. If I use @ref,
> it breaks the info build. So I had to use @rlearning to get it to pass make
> doc.
>
> If I'm doing something wrong, and there's some way to get @ref to work, I'd be
> happy to know about it.
@ref definitely should work. It may be that the heading for one
of them is "Articulation and dynamics", not "Articulations and
dynamics" - no "s". Using @ruser bypasses the check, I think.
Message from c_sorensen@byu.edu
2018-04-30T17:16:13+00:00c_sorensenurn:md5:e02b958f94068c9c5d75f899805dc0f0
On 4/30/18, 11:04 AM, "lilypond-devel on behalf of tdanielsmusic@googlemail.com" <lilypond-devel-bounces+c_sorensen=byu.edu@gnu.org on behalf of tdanielsmusic@googlemail.com> wrote:
@ref definitely should work. It may be that the heading for one
of them is "Articulation and dynamics", not "Articulations and
dynamics" - no "s". Using @ruser bypasses the check, I think.
OK, that's clearly the issue.
Now, how should it be fixed? Should we stick with "Articulation and dynamics", even though the next menu down is "Articulations"? Or should we change to "Articulations and dynamics"? I can do either one.
Thanks,
Carl
Message from t.daniels@treda.co.uk
2018-04-30T17:29:13+00:00t.daniels_treda.co.ukurn:md5:b22429c70ae44f2d395d8faeea11af1f
Carl, you wrote 30/04/2018 18:16:05
>
>On 4/30/18, 11:04 AM, "lilypond-devel on behalf of
>tdanielsmusic@googlemail.com"
><lilypond-devel-bounces+c_sorensen=byu.edu@gnu.org on behalf of
>tdanielsmusic@googlemail.com> wrote:
>
> @ref definitely should work. It may be that the heading for one
> of them is "Articulation and dynamics", not "Articulations and
> dynamics" - no "s". Using @ruser bypasses the check, I think.
>
>OK, that's clearly the issue.
>
>Now, how should it be fixed? Should we stick with "Articulation and
>dynamics", even though the next menu down is "Articulations"? Or
>should we change to "Articulations and dynamics"? I can do either one.
Well, I'd prefer adding the "s" to the title, as long as it doesn't
break other references (I don't know if there are any, but if there are
any in the LM they should show up as errors in a make doc.)
Documentation/scripts/auxiliar/ref_check.py should check all refs for
you, if it still works - it's a while since I used it.
Trevor
Message from unknown
2018-04-30T19:18:40+00:00Carlurn:md5:5a9972991709c8cfb4b39640802dbf37
Message from Carl.D.Sorensen@gmail.com
2018-04-30T19:18:42+00:00Carlurn:md5:a993b089ff72743c8ac59c555f6e03de
Adjust titles and menus
Message from thomasmorley65@gmail.com
2018-04-30T21:49:37+00:00thomasmorley651urn:md5:a8c43b9ffeb58f4648e84ee18fb3a738
Hi Carl,
many thanks for your work.
Some remarks:
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (right):
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely#newcode465
Documentation/learning/fundamental.itely:465: optionally followed by one or more post-events. Post-events add
I'd completely delete 'post-event'.
From a musical thinking it makes no sense. An articulation is not performed _after_ the note.
To explain it programmatical, this is not the right place, imho.
Why not simply:
"A note entry in LilyPond consists of a pitch, followed by a duration, optionally followed by things such as articulations, fingerings, string numbers, slurs, ties, explanatory text, etc."
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely#newcode481
Documentation/learning/fundamental.itely:481: Post-events follow the note to which they are attached. Suppose we
Here as well.
Also, I think it's important to drop a sentence about the "-"-signs, which actually attach those optional elements to the note.
So my suggestion:
"Optional elements are added at the end of the initial note-duration-entry. Probably using a "-"-sign, which can be omitted, if no ambiguity occurs.
Suppose we ..."
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely#newcode488
Documentation/learning/fundamental.itely:488: {c'8-1--(~^\markup{"text annotation"} c' d')}
For the sake of simplicity I'd not use direction-modifiers and enter the text without explicit \markup, i.e.:
{c'8-1--(~-"text annotation" c' d')}
Message from Carl.D.Sorensen@gmail.com
2018-04-30T22:19:12+00:00Carlurn:md5:7c8327abf19f7eb3a4b433c5c0d6b437
Harm,
Thanks for the input. I'm not sure I agree with you on all this, but I'm certainly open to being convinced. I've got specific replies to your inline comments.
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (right):
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely#newcode465
Documentation/learning/fundamental.itely:465: optionally followed by one or more post-events. Post-events add
On 2018/04/30 21:49:37, thomasmorley651 wrote:
> I'd completely delete 'post-event'.
> From a musical thinking it makes no sense. An articulation is not performed
> _after_ the note.
> To explain it programmatical, this is not the right place, imho.
>
> Why not simply:
>
> "A note entry in LilyPond consists of a pitch, followed by a duration,
> optionally followed by things such as articulations, fingerings, string numbers,
> slurs, ties, explanatory text, etc."
We could do this. But ultimately all the things that attach to notes like this are called post-events in the internals reference. So I don't think it's a bad idea to introduce the LilyPond term here, just like we do for pitch and duration. All three terms (pitch, duration, post-event) are LilyPond terms, not musical terms.
We aren't explaining music in this section. We are explaining LilyPond constructs.
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely#newcode481
Documentation/learning/fundamental.itely:481: Post-events follow the note to which they are attached. Suppose we
On 2018/04/30 21:49:37, thomasmorley651 wrote:
>
> Here as well.
>
> Also, I think it's important to drop a sentence about the "-"-signs, which
> actually attach those optional elements to the note.
>
> So my suggestion:
>
> "Optional elements are added at the end of the initial note-duration-entry.
> Probably using a "-"-sign, which can be omitted, if no ambiguity occurs.
> Suppose we ..."
>
>
I don't think I agree that things are attached with "-" signs. For example, \staccato, \mordent, \turn, \fermata, \prall, (, [. None of these are attached with "-" signs, although they can have a direction indicator (-, _ , ^) preceding them if desired. At least, that is what the N.R. 5.4.2 says.
If we want to talk about direction indicators here, I think we can give a brief introduction. If not, I think we should leave them out completely. In the LM and the NR, the direction indicators are always included when we add the post-events, if they are needed.
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely#newcode488
Documentation/learning/fundamental.itely:488: {c'8-1--(~^\markup{"text annotation"} c' d')}
On 2018/04/30 21:49:37, thomasmorley651 wrote:
>
> For the sake of simplicity I'd not use direction-modifiers and enter the text
> without explicit \markup, i.e.:
> {c'8-1--(~-"text annotation" c' d')}
I think it's actually nicer not to have so many "-" characters; they make it confusing, in my opinion.
Message from thomasmorley65@gmail.com
2018-04-30T22:55:35+00:00thomasmorley651urn:md5:d9d58375d9f1fe47fd8ab49311740ce8
On 2018/04/30 22:19:12, Carl wrote:
> https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely
> File Documentation/learning/fundamental.itely (right):
>
> https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely#newcode465
> Documentation/learning/fundamental.itely:465: optionally followed by one or more
> post-events. Post-events add
> On 2018/04/30 21:49:37, thomasmorley651 wrote:
> > I'd completely delete 'post-event'.
> > From a musical thinking it makes no sense. An articulation is not performed
> > _after_ the note.
> > To explain it programmatical, this is not the right place, imho.
> >
> > Why not simply:
> >
> > "A note entry in LilyPond consists of a pitch, followed by a duration,
> > optionally followed by things such as articulations, fingerings, string
> numbers,
> > slurs, ties, explanatory text, etc."
>
> We could do this. But ultimately all the things that attach to notes like this
> are called post-events in the internals reference. So I don't think it's a bad
> idea to introduce the LilyPond term here, just like we do for pitch and
> duration. All three terms (pitch, duration, post-event) are LilyPond terms, not
> musical terms.
Pitch and duration are surely terms every musician and every music-typesetter will know, they are _musical_ terms as well.
Not so post-event.
Maybe it would be sufficient to reword:
"optionally followed by one or more elements, which are called "post-events".
>
> https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely#newcode481
> Documentation/learning/fundamental.itely:481: Post-events follow the note to
> which they are attached. Suppose we
> On 2018/04/30 21:49:37, thomasmorley651 wrote:
> >
> > Here as well.
> >
> > Also, I think it's important to drop a sentence about the "-"-signs, which
> > actually attach those optional elements to the note.
> >
> > So my suggestion:
> >
> > "Optional elements are added at the end of the initial note-duration-entry.
> > Probably using a "-"-sign, which can be omitted, if no ambiguity occurs.
> > Suppose we ..."
> >
> >
>
> I don't think I agree that things are attached with "-" signs. For example,
> \staccato, \mordent, \turn, \fermata, \prall, (, [. None of these are attached
> with "-" signs, although they can have a direction indicator (-, _ , ^)
> preceding them if desired. At least, that is what the N.R. 5.4.2 says.
Here the NR is not entirely complete.
"_" and "^" _are_ direction-modifiers, ofcourse.
"-" _is_ the method to insert a post-event into a list of other post-events.
For convenience it can be omitted, if no ambiguity is present. (It can't be omitted before a fingering, for example)
The direction of this post-event is the default-direction for said post-event. But this more a side-effect.
Also, see:
{ \displayLilyMusic c'\tenuto }
=> c'4--
>
> If we want to talk about direction indicators here, I think we can give a brief
> introduction. If not, I think we should leave them out completely.
Agreed, direction-modifiers shouldn't be explained here in the fundamentals.
> In the LM
> and the NR, the direction indicators are always included when we add the
> post-events, if they are needed.
>
> https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely#newcode488
> Documentation/learning/fundamental.itely:488: {c'8-1--(~^\markup{"text
> annotation"} c' d')}
> On 2018/04/30 21:49:37, thomasmorley651 wrote:
> >
> > For the sake of simplicity I'd not use direction-modifiers and enter the text
> > without explicit \markup, i.e.:
> > {c'8-1--(~-"text annotation" c' d')}
>
> I think it's actually nicer not to have so many "-" characters; they make it
> confusing, in my opinion.
Ofcourse, but I don't understand the relevance here.
{c'8-1--(~-"text annotation" c' d')} does not use more "-" than the other code.
Btw, maybe better to add a space after { and before }.
Message from thomasmorley65@gmail.com
2018-04-30T23:47:56+00:00thomasmorley651urn:md5:6e942572f8ff8dfd74740a9abab532f5
On 2018/04/30 22:55:35, thomasmorley651 wrote:
> On 2018/04/30 22:19:12, Carl wrote:
> > I don't think I agree that things are attached with "-" signs. For example,
> > \staccato, \mordent, \turn, \fermata, \prall, (, [. None of these are attached
> > with "-" signs, although they can have a direction indicator (-, _ , ^)
> > preceding them if desired. At least, that is what the N.R. 5.4.2 says.
>
> Here the NR is not entirely complete.
> "_" and "^" _are_ direction-modifiers, ofcourse.
> "-" _is_ the method to insert a post-event into a list of other post-events.
> For convenience it can be omitted, if no ambiguity is present. (It can't be
> omitted before a fingering, for example)
> The direction of this post-event is the default-direction for said post-event.
> But this more a side-effect.
>
> Also, see:
> { \displayLilyMusic c'\tenuto }
> => c'4--
Well, I had a look in parser.yy. Although, I can't say I really understand it, I'm not longer sure above is true.
Maybe David K can say more.
Message from Carl.D.Sorensen@gmail.com
2018-05-01T02:47:20+00:00Carlurn:md5:c99254afb01a89b92087c04503d89f48
According to parser.yy:
In line 3259, a post_event is either:
1) post_event_nofinger, or
2) '-' plus a fingering
In line 3200, a post_event_nofinger is either
1) direction_less_event
2) script_dir plus a music_function
3,4 ) Lyric hyphen or lyric extender (Not relevant to this discussion).
5) script_dir plus a direction_reqd_event
6) script_dir plus a direction_less_event
7) '^' plus fingering
8) '_' plus fingering
In line 3275, a direction_less_event is either
1) string_number_event
2) tremolo
3)event_function_event
In line 3288, a direction_reqd_event is either
1) gen_text_def
2) script_abbreviation
In line 3387, a gen_text_def is either
1) full_markup
2) STRING
3) SYMBOL
4) embedded_scm
In line 3413, a fingering is
1) UNSIGNED
The way I read this, NR 5.4.2 is exactly right. A direction indicator is required for
1) markups (gen_text_def case 1)
2) strings (gen_text_def case 2)
3) abbreviated forms of articulations (script_abbreviation)
4) fingerings (post_event case 2, direction_less_event case 7, direction_less_event case 8)
5) \tweak or \tag (I'm not sure about this, but I think it's gen_text_def case 4)
Given this, I don't think we should say that '-' is what we use to insert post_events.
I am of the opinion that we should not include '-' as a specific element in this discussion. I think it should say as-is.
Thanks,
Carl
Message from dak@gnu.org
2018-05-01T03:26:24+00:00dakurn:md5:fdf8aa0c55b8108eb12b12dde3b7c6d5
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (right):
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely#newcode465
Documentation/learning/fundamental.itely:465: optionally followed by one or more post-events. Post-events add
On 2018/04/30 22:19:12, Carl wrote:
> On 2018/04/30 21:49:37, thomasmorley651 wrote:
> > I'd completely delete 'post-event'.
> > From a musical thinking it makes no sense. An articulation is not performed
> > _after_ the note.
> > To explain it programmatical, this is not the right place, imho.
> >
> > Why not simply:
> >
> > "A note entry in LilyPond consists of a pitch, followed by a duration,
> > optionally followed by things such as articulations, fingerings, string
> numbers,
> > slurs, ties, explanatory text, etc."
>
> We could do this. But ultimately all the things that attach to notes like this
> are called post-events in the internals reference. So I don't think it's a bad
> idea to introduce the LilyPond term here, just like we do for pitch and
> duration. All three terms (pitch, duration, post-event) are LilyPond terms, not
> musical terms.
>
> We aren't explaining music in this section. We are explaining LilyPond
> constructs.
"pitch" and "duration" are certainly valid musical terms outside of LilyPond and describe musical entities even within LilyPond. "post-event" does not carry meaning separate from the LilyPond grammar.
It might make sense to introduce it as a LilyPond term by putting it in quote marks first mention:
one or more @q{post-events}. Post-events are placed after a main event in the input and constitute things such as ...
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely#newcode481
Documentation/learning/fundamental.itely:481: Post-events follow the note to which they are attached. Suppose we
On 2018/04/30 22:19:12, Carl wrote:
> I don't think I agree that things are attached with "-" signs.
It's more a less a matter of what one wants to declare the rule and what the exception. It's more of a semantic difference, so it's more the question of which view might be more helpful.
I'd lean towards keeping your version here: I think it better matches what we use elsewhere.
Message from thomasmorley65@gmail.com
2018-05-01T20:14:34+00:00thomasmorley651urn:md5:af5ce2776389e36176b4b8e4c3230eb7
On 2018/05/01 02:47:20, Carl wrote:
> According to parser.yy:
>
> In line 3259, a post_event is either:
>
> 1) post_event_nofinger, or
> 2) '-' plus a fingering
>
> In line 3200, a post_event_nofinger is either
>
> 1) direction_less_event
> 2) script_dir plus a music_function
> 3,4 ) Lyric hyphen or lyric extender (Not relevant to this discussion).
> 5) script_dir plus a direction_reqd_event
> 6) script_dir plus a direction_less_event
> 7) '^' plus fingering
> 8) '_' plus fingering
>
>
> In line 3275, a direction_less_event is either
> 1) string_number_event
> 2) tremolo
> 3)event_function_event
>
> In line 3288, a direction_reqd_event is either
> 1) gen_text_def
> 2) script_abbreviation
>
> In line 3387, a gen_text_def is either
> 1) full_markup
> 2) STRING
> 3) SYMBOL
> 4) embedded_scm
>
> In line 3413, a fingering is
> 1) UNSIGNED
>
> The way I read this, NR 5.4.2 is exactly right. A direction indicator is
> required for
> 1) markups (gen_text_def case 1)
> 2) strings (gen_text_def case 2)
> 3) abbreviated forms of articulations (script_abbreviation)
> 4) fingerings (post_event case 2, direction_less_event case 7,
> direction_less_event case 8)
> 5) \tweak or \tag (I'm not sure about this, but I think it's gen_text_def case
> 4)
>
> Given this, I don't think we should say that '-' is what we use to insert
> post_events.
>
> I am of the opinion that we should not include '-' as a specific element in this
> discussion. I think it should say as-is.
>
> Thanks,
>
> Carl
Hi Carl,
in the light of your findings and David's reply (#17) I changed my mind about those "-"-signs and now agree we should not make them a topic here.
Anyway, I found the discussion very instructive, helping me to get a deeper understanding. I hope it was not too tedious for you.
So two suggestions remaining:
I'd like to second David with putting quotation marks around the first mentioning of post-events.
Spaces after/before {}. If I've counted correctly it's emphasized three times in the LM...
Otherwise
LGTM
Thanks,
Harm
Message from dak@gnu.org
2018-05-01T20:31:36+00:00dakurn:md5:68dbea1d0d9adc6f98a5d30b814b4549
On 2018/05/01 20:14:34, thomasmorley651 wrote:
> in the light of your findings and David's reply (#17) I changed my mind about
> those "-"-signs and now agree we should not make them a topic here.
> Anyway, I found the discussion very instructive, helping me to get a deeper
> understanding. I hope it was not too tedious for you.
One really has to understand that the rules in the grammar describe what constructs are accepted and interpreted in what manner. They don't assign a logic or meaning to them. It makes the grammar easier to read when the rules are laid according to a higher-level plan, but the restrictions of an LALR(1) parser generator (which is what the rules are written for) don't leave a lot of leeway of expressing the concepts of LilyPond straightforwardly.
In addition, quite a bit of the "inherent logic" has been designed after the fact and then those rules/productions not matching that logic have been meddled with.
The grammar is the ultimate source of information about how LilyPond will behave, but not what that means. That's ultimately for the documentation writers to decide.
Message from unknown
2018-05-02T23:13:53+00:00Carlurn:md5:11e0a178d8a5e66801f3ef26fd4a5353
Message from Carl.D.Sorensen@gmail.com
2018-05-02T23:13:54+00:00Carlurn:md5:801a2c262100d69a6c4b12d7a8215539
Adjust description of post-events