lilypond-devel
[Top][All Lists]
Advanced

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

Lilypond Syntax Development and 3.0


From: Graham Percival
Subject: Lilypond Syntax Development and 3.0
Date: Mon, 27 Jul 2009 03:22:33 -0700
User-agent: Mutt/1.5.18 (2008-05-17)

I was going to hold off introducing this until the 3-4 major
development issues had been sorted out, but the third time I found
myself writing "yes, I have a plan for this, but I'm going to wait
a bit before discussing it", I decided I was behaving like a
smarmy teenager.

There's nothing time-critical in this thread, so if you're
currently working on anything important, skip this email and come
back to it later.  We won't make any real decisions for a week or
so.


Lilypond Syntax Development   (tentative name)

One of the biggest complaints people have with lilypond -- other
than that silly "there's no gui" -- is the changing syntax.  Now,
inventing a language or standards is difficult.  If you set it in
stone too soon, you risk being stuck with decisions which may
limit matters.  If you keep on updating the syntax, interaction
with older data (and other programs!) becomes complex.

However, I think we now have a critical mass of interested users,
experience with the syntax, and developers.  I therefore propose
to have a Grand Project devoted to stabilizing the lilypond input
format.


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)
Once this is finished, we will release lilypond 3.0.


LIMITATIONS and SCOPE

- tweaks will not be included.  Anything with \override, \set,
  \overrideProperty, \tweak, \revert, \unset, #(blah blah) ...
  including even those names themselves... is still fair game for
  NOT_SMART convert-ly updates.

- other than that, everything is on the table.  Is it a problem to
  have the tagline inside \header?  What should the default
  behavior of \include be?  When we abolish \times, do we move
  to \tuplet 3:2 or \tuplet 2/3 or what (for typical triplets
  in 4/4 time)?

- we need to get standards for commands.  This will help users
  remember them, and reduce the options for future names (and
  potential renamings later on).  \commandOn and \commandOff
  seem to work well (should we *always* have an Off command?),
  but what about the "command" part?  Should it be \nounVerbOn,
  or \verbNounOn ?  Or \verbNotesWithExtraInformationOn ?

- we need standards for the location of commands.  Ligature
  brackets, I'm looking at you.  (non-postfix notation must die!)

- this Grand Project doesn't change whether we have a 2.16 or
  not.  The main problem will be deciding what to do (with a
  bit of messiness anticipated for \tuplet); we could definitely
  release a 2.16 before merging _any_ of these changes.

- we obviously can't /guarantee/ that we'll /never/ make any
  non-convert-ly changes in the basic format.  But we *can*
  guarantee that such changes would force lilypond 4.0, and
  that we would only do so for overwhelmingly good reasons.


WORKFLOW

- 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.

- I could be convinced to use the lilynet wiki for this project,
  although we'd need account-locked pages, and it would increase
  my workload.

- after the initial discussion of proposals has died down, I'll
  bring it to -devel.  We're not going to make any (significant)
  changes without discussing it on -devel, but we're going to
  have huge threads about English grammar and silly ideas, and
  I don't want to clutter up -devel.  Once whatever chaotic
  silliness on the syntax list is settled down, I'll bring the
  ideas to -devel.

- as with GDP, I'll moderate the discussion.  Not as with mailist
  moderation, but rather by introducing issues at specific
  times.  We don't want a free-for-all discussion of all parts
  of the syntax at once; nothing will get resolved.


DISCUSSION

Don't respond to any of the specifics yet.  Yes, we all have our
pet irritations (like "what the mao is up with \paper and
\layout?!").  There will be plenty of time to discuss them.  At
the moment, I'm looking for comments about the mandate -- what's
the scope, how much interest is there, and does anybody object to
such work?


CRESCENDO

Reinhold and Frederick: as you may have guessed, I'm proposing
that your patch waits until 3.0.  Anything requiring such manual
tweaks will make some people very unhappy, such as mutopia.

I think we should make *all* manual changes at once, but reassure
people that this will (probably) be the last time (for non-tweaked
scores, at least).

This also serves as test of developers: we've avoided getting
"pinned down" with the input syntax because that would limit
development.  How do you two feel about your hard work on the \cr
stuff being delayed by up to a year?  I don't like asking this,
but I think there are solid reasons for it.

Cheers,
- Graham





reply via email to

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