On Tue, Apr 27, 2004 at 12:01:00PM -0400, Steven Bennett wrote:
> > Here's a compromise: perhaps the parser can have a function like the above
> > that takes only one tune, that is, takes a string that starts with "X:", and
> > ends just before the next "X:" command. Then there would be a super-parser
> > (trivial to write) that breaks the string on "X:" boundaries. I'm guessing
> > that most applications would be concerned with just one tune at a time,
> > anyway.
>
> Actually, this is sort of close to what my parser is doing, but you're
> missing one *very* important thing -- the file fields. At the beginning of
> the file (prior to the first X: or T:) and in-between tunes (ie. After the
> first blank line in a tune, which ends the tune, and before the next X: or
> T:) there may be a variety of settings which can affect the remaining tunes
> in the file. In the ABC spec, these are the fields marked "Yes" for "File".
> Their existence complicates the job considerably.
>
> Note that while ABC 1.6 and 1.7.6 explicitly allow these fields in-between
> tunes, ABC 2.0 draft states they can only be at the beginning of a file.
> (There really ought to be a note about this in the Deprecated Syntax
> section... Or the restriction should be lifted.)
Yes. One consequence of this restriction is that abc files can become
"invalid" just by being cut&pasted together. If you have 2 files, each
with file-scope fields at the top, a simple
cat file1.abc file2.abc > file12.abc
will produce a file with headers between tunes. Forbidding this may make
life easier for simple parsers, but I don't think it's desirable for
users.
--
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
