On Mon, Sep 15, 2003 at 06:15:51PM +0100, Barry Say wrote: > After much consideration and a little discussion, I have devised some > modifications to the ABC standard, which I think could make the > structure considerably more elegant without doing to much damage to > existing applications. As they are rather complex I have described > them on a web page: > > www.nspipes.co.uk/barry/abc2propos_r1.html > > I would welcome any comments on or off list.
Slow following this up, I'm sorry, I've been a bit taken up with other things. And - I'm not sure where to start, with commenting on this. As you say, it doesn't necessarily imply very much change in the way ABC is written, but requires changes in the understanding we have of what we write/read. Interesting. And elegant, yes. The "field:<optional label><space>value" could be a very neat way out of what's been a problem, the limited number of single letters for fields; but could lead to a mess of proliferation similar to what we have now with the "%%" directives, if everybody starts inventing their own labels. Would we want to write some "standard" labels into the definitions of the fields in a new "new proposed standard", in the same way that you propose some for the I: field ? - which, likewise, offers a neat way out of the mess of proliferating directives. I like it. minor comments ... You remark, having all music lines fit into a field, either explicitly or 'virtually' means that "there is now virtually no need for a continuation character". But, as you also remark elsewhere, it's still needed for hiding the linebreak=staffbreak behaviour, which I guess is maybe its most common use. Y: for copyright - yes. I think copyright is important enough to need a field of its own, the lack of a general way to write this has been conspicuous for a long time. As for the questions at the end ... what changes would be needed ? I can't see many ways in which existing ABC wouldn't be readable by software written to these ideas, except for the possible lack of a space after a fieldkey, and that "free text" wouldn't be marked wih a t: field, both of which would be fairly fixable. I've probably missed lots of points, though. ABC written to these ideas would be more of a problem for existing software, with key-labels being understood as part of the field values; and maybe an unvalued "V:" would break some software ? As for whether the developers would write software ? ...???...??? And the perennial question - ABC is easy for humans. The worst I can think of is that the "text-editor brigade" would omit the space after the field-key if they did't want to use the labelling syntax. Which would revert it to the existing syntax. It would be interesting to see a new abc2mtex, after all these years :) -- 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
