As I remember, the real problems with the continuation---apart from the incompatibility of 1.6 and 2.0---come when there was a mixed bag: several staves, lyrics, etc. In that case, there are natural musical groupings, and there was a discussion on how, or whether, to have "smart continuations" which would work on a whole group, or within a group. A few ideas were suggested. Barry Say made a fairly far-reaching proposal for doing this, but I don't think the discussion continued much beyond that point.
Cheers, John Walsh Steve Bennett writes: >Hi! > >I'm in the process of writing Yet Another ABC Parser as part of a larger project I've been working on for a while. (There are umpteen jillion reasons why I'm not using an existing parser - the biggest being this one is written in Objective C, but that's besides the point...) Ideally I'd like this to be able to handle files which conform to ABC 1.6, ABC 1.7.6, and the ABC 2.0 draft spec (dated Aug 14, 2003), but there are numerous little quirks and differences. The quirk I'm wrestling with today is Continuation Lines, which seems to be the biggest single area (and the biggest can of worms on the list archive) where the 1.6 & 1.76 specs seriously conflict with the 2.0 draft spec. Files written one way will parse ONLY if you use the 1.6/1.7.6 method, and files written another way will parse ONLY with the 2.0 method. And I don't see any mechanism (short of a good AI) to figure out which way during the parse. So I'm going to implement both and allow the user to decide which to use via a runtime switch. So... The 2.0 continuation line specification is almost trivial to implement. The only area which could use a bit of clarification there is it's effect during History fields. For example: ... H: This is some history This continues the history So does this And this too %%and this isn't an xcommand % But is this a comment? If you display % the history field, is it included? % I believe the answer should be No... And what about this? X \ Would this appear on the same line as the "X" \ If the history was displayed to the user? (IMHO, Yes) And here's the real challenge: \ % oh boy O: Is this the Origin or part of the History? I think it's part of the history myself And that *this* line is the last line of the history. O: This is the real origin... ... Does this interpretation of the ABC 2.0 variant make sense? Comments aren't actually part of the history field, and continuations *do* apply? As for the 1.6 and 1.7.6 specifications, regardless of what program X, Y, or Z does, the written spec is awfully vague. I have several possible approaches to different elements of this, but the basic concept appears to be that "\" at the end of a line isn't so much a continuation, but a "don't break the staff here if you would normally". Taking that as a given, then "\" would only be meaningful on tune body or lyric lines, and ignored (possibly generating warnings) on other fields. It would not allow putting field-like text inside a History field as described above. You would also require the "w:" at the start of the continued lyric line, unlike 2.0 which would require it NOT be there. Does anyone see anything I'm missing here? The question becomes how to deal with comments. I saw plenty of discussion of whether the "\" is ignored if it follows a comment, or whether it's invalid if it isn't the very last character on the line. I guess it depends on whether you look for the "\" first or the comment first. Is there any consensus out there as to which is the proper approach when you are parsing files using pre-2.0 continuations? (Or should I make *that* a user switch as well...) -->Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
