Except I'm only proposing this as an aid in defining how to parse 1.* style
completions (when the user has selected that as a parsing flag...), not as a
change to the 2.0 spec. I actually prefer the 2.0 continuation mechanism,
although I'm not strongly attached to it and could see how the 1.* style,
defined the way I suggested, could actually make more sense.
(Especially, as I think about it, in light of the %%continueall XCommand,
which certainly should NOT behave as if one had placed a 2.0 style
continuation on each line, but *should* behave, IMHO, as if there was a 1.*
style continuation there...)
As for the "all voices" line, I'm not sure I like that idea all that much --
it creates a new parsing state which opens up a number of cans of worms -
specifically what is legal when you are in an "all voices" section and what
is not.
Possibly a better approach would be using something like [V:*=S] to assign
the current voice specific settings of voice "S" to all other voices. That
field would *not* have the side effect of changing voices. (You might also
allow [V:A=S] or the like.) So your line below:
[V:*] [K:G] [M:3/4]
...might instead read:
[V:S] [K:G] [M:3/4] [V:*=S]
...and you would end up being in voice "S".
I don't know if I like that much either (you still need to define *exactly*
which voice specific settings get copied and which do not), but from a
parsing point of view, I much prefer it over what you were suggesting.
-->Steve Bennett
> 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
>>
>
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
