[Top][All Lists]

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

Re: Lilypond Syntax Development and 3.0

From: Graham Percival
Subject: Re: Lilypond Syntax Development and 3.0
Date: Mon, 3 Aug 2009 05:23:35 -0700
User-agent: Mutt/1.5.18 (2008-05-17)

On Sun, Aug 02, 2009 at 08:48:01PM +0200, John Mandereau wrote:
> Le lundi 27 juillet 2009 à 03:22 -0700, Graham Percival a écrit :
> > One of the biggest complaints people have with lilypond -- other
> > than that silly "there's no gui" -- is the changing syntax.  Now,
> IMHO this project should be an opportunity to promote Erik Sandberg's
> music streams as a more stable music data representation before making
> syntax changes that can't be handled by regular expressions and that
> break a lot of source files.

I think that's beyond us.  Unless Erik or Han-Wen decide to
implement it, I'm almost certain that this work will go nowhere.
And since it's been 3 years since the thesis was finished, I think
that if they wanted to do it, they'd have finished it.
Understanding somebody else's half-finished work can be harder
than doing it from scratch, after all!

Basically, I don't see an overabundance of programmers with deep
knowledge of lilypond internals (which is what the music streams
would require).  I *do* see an overabundance of intelligent people
who see the value of creating general principals and rules.  I'm
certain that we can simplify+standarize the lilypond input
notation, and I'm certain that I can organize such an effort.  I'm
not *at all* certain[1] that I could organize an attempt to
implement the music streams.

Umm, I don't mean "overabundance" as in "there's too any of them".
I'm using some other meaning of "overabundance" here.  :)

[1] or rather: I'm certain that if I cared deeply about this, I
could do it.  I simply don't care deeply about it -- I mean, I
wouldn't sacrifice any academic matters in favor of working on
music streams, whereas I _would_ sacrifice some academic matters
in favor of GLISS or the normal lilypond maintenance.

I n any case, I don't anticipate that GLISS would create many
non-convert-ly changes.  The main manual change would be the
prefix -> postfix change (\cr, \[, maybe one or two others).  In
theory, those could be automated, but since we probably won't have
anybody who feels like writing python rules for that, we could
just change \cr to \PREcr.  That would identify the places were
\PREcr needs to be moved and changed to \cr.

- Graham

reply via email to

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