Re: a better convert-ly

[Erik Sandberg]

On Friday 17 December 2004 01.08, Han-Wen Nienhuys wrote:
> address@hidden writes:
> > > The syntax of basic music input hasn't changed appreciably since
> > > lilypond-2.0. For the future, we have plans to build a GNOME-based GUI
> > > for tweaking, which completely separates out tweaks into different
> > > files.  I don't really see what else we can do.
> >
> > I didn't yet get any response to my ideas about outputting an
> > intermediate format.. does this mean it's a bad idea?
>
> It's a nice idea, but if the "lowlevel" file is going to be edited
> automatically, it doesn't make sense to try make it
> human-readable. Just use what comes out of input/no-notation/to-xml.ly

There is a point in making it human-readable; namely that it could be made a 
subset of the .ly language. The point with this would be that as a 
side-effect, one could create a complete (but lossy in source layout) 
convert-ly tool, for future compatibility.

But, of course, this could be accomplished with xml intermediate format + a 
complete xml2ly as well. (xml here refers to any non-ly intermediate format)

Hm.. subset-of-ly vs xml arguments:
- With ly, we would have to use 2 different (independent) parsers for almost 
the same language. If one changes, both have to change. Could become a bit 
dirty.
- With xml, we would have to maintain a complete xml2ly script, and perhaps a 
convert-xml for the unusual event of changes in format. Possibly, more 
documentation will have to be written.
- saving back changes to ly is probably harder than to xml.

xml looks like a fair choice, as long as we write a tool that can convert it 
back to equivalent .ly code (i.e. "xml2ly foo.xml | ly2xml -" should be like 
'cat foo.xml' if that file was created by lily).

Erik