lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lilypond Syntax Development and 3.0


From: David Kastrup
Subject: Re: Lilypond Syntax Development and 3.0
Date: Mon, 27 Jul 2009 13:31:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

A few comments from a consumer...

Graham Percival <address@hidden> 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 address@hidden 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]