A few comments from a consumer... Graham Percival <gra...@percival-music.ca> writes:
> SUMMARY > > Start: Sep 2009. > > Length: 6-9 months. We're not going to rush this. > > Goal: define an input format which we commit to being > machine-updateable for the forseeable future. Any future patches > which change the syntax in a non-convert-ly-able format will be > rejected. (subject to the limitations, below) > > LIMITATIONS and SCOPE > > - We're going to have lots and lots of emails flying around. They > don't really fit into either -devel or -user, so we'll use a > mailist on lilynet.net. Maybe the already-created proposals > mailist, maybe a syn...@lilynet.net mailist. Huh? Why would a discussion about syntax not fit into -devel? Anyway, here is my thought: we want a reliably machine-readable and writable input. Everything that does not concern the art of typesetting should be accessable easily from a C parser library. Of course I have my own pet language for manipulating score material (Lua), but then many people do. If one has something like a flex/bison syntax and/or a parser library and/on definite rules for what can, can't be done, then one has a lot of flexibility. The level one would like is that reading lilyput input and writing a lilyput input file that does the same, just transposing a voice, should not take more than 10 lines of code/script. Also reading an input file and writing an equivalent input file (just not using \input anymore) should be easy to do. In a similar vein, score editors should be able to export and import Lilypond code with an expectation of not having information loss occur (short of whitespace/source formatting, and possibly that can be preserved using intelligent schemes as well that keep track of manual source line breaks, indentation and comments). -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
