I like this way of doing it. I think that it is clearer than
what I was proposing a couple days ago. This would mean that
the backslash at the end of a line does not have the semantics
currently written in the 2.0 spec, but it is more backward
compatible with 1.x, it is defined well enough to parse without
ambiguity, and it does everything that seems to be needed.
If we had the ability to specify an "all voices" line, that
would complete it :-). Then we could write my previous example
as (with a little more detail):
X:1
T:test
M:C
L:1/8
K:D
[V:S] ccAb ccA2 | fdab \
w: a-a-a-a a-a-a-a | a-a-a-a \
[V:A] ccAb ccA2 | fdab \
w: i-i-i-i i-i-i-i | i-i-i-i \
[V:*] [K:G] [M:3/4]
[V:S] xd | c3 c3 |
w: a-a | a a |
[V:A] xd | c3 c3 |
w: i-i | i i |
And it is perfectly clear what it is supposed to do. There is
no ambiguity about what the backslashes relate to. Although,
you should modify your statement so that it can occur on
tune, lyric, and symbol lines (add the symbol to the list).
tom
Steven Bennett said:
>>> So... If it can only occur on tune and lyric lines, and it can only
>>> occur
>>> where a staff break or lyric line break would be valid, then that is
>>> why I
>>> suggested a definition along the lines of:
>>>
>>> "A backslash ("\") at the end of a line means do not break the staff or
>>> lyric line at this point if that's what would happen because of the
>>> following line ending."
>>>
>>> It becomes pretty straightforward (actually fairly easy) to parse if
>>> you
>>> define it that way, and seems fairly consistent with the 1.* usage.
>>>
>>>
>>> Anyone see any gaping holes in that logic?
>>>
>>
>> You have still left open the question of whether programs should look
>> for a simple continuation on the next line, or look for a field
>> identifier if appropriate. (e.g. a w: field)
>
> Actually, I think that by phrasing it the way I did above, there is no
> assumption made at all about the next line, so it's parsed exactly as you
> would parse any other field/tune data line. I'm basically avoiding the
> term
> "continuation" in 1.* parsing because that confuses the issue -- I see it
> as
> not so much a continuation as a break/no-break flag on the line.
>
> The assumption I *am* making is that the decision to break the staff or
> lyric line is made when the end of line is parsed. Without a "\"
> character,
> the staff or lyric line is normally broken. With a "\" just before the
> end
> of line, the staff or lyric line is not broken.
>
> Thus, for a w: field with a "\" at the end, you *would* have the "w:" on
> the
> next lyric line, which doesn't have to happen immediately.
>
> Of course, this begs another 1.* specific question - should I ignore "\"
> at
> the end of non tune data or lyric lines, or flag them as parse errors or
> warnings? For simplicity, I'm leaning towards simply ignoring them.
>
> -->Steve Bennett
>
> To subscribe/unsubscribe, point your browser to:
> http://www.tullochgorm.com/lists.html
>
--
tom satter - or just plain old tom
(303) 543-7623 (home)
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
