On Sat, Sep 1, 2012 at 10:09 PM, David Kastrup <d...@gnu.org> wrote: > Well, the music function work has removed a lot of pressure of the "I > want my favorite construct xxx in the grammar" kind since there are > quite a number of things people can put in themselves if they want to. > Yes, the process of making music functions more versatile was quite > undemocratic. But it was not as much that I was sole decision-maker, > but rather that my skills and areas of interest were shaping the work I > was doing, with a focus of making currently existing constructs > reimplementable in Scheme. > > The direction that LilyPond's parser is taking is increasingly > supporting _constructs_ as contrasted to _elements_. So there is much > more inclination nowadays to ask oneself the question "how can I express > this with existing tools?" rather than "how can I fit this into the > parser as well?".
I'm not sure if i understand. Could you give some examples? > Locking people away in a syntax discussion list, then ignoring them or > having to deal with the consequences does not sound like a strategy fair > to either those interested in changes, nor to those not interested but > affected by such changes. Huh? Didn't Graham ditch the idea of separate syntax list? I think we decided to discuss everything on -devel, and with proper labelling it should be not too messy. On Sat, Sep 1, 2012 at 10:58 PM, Nicolas Sceaux <nicolas.sce...@gmail.com> wrote: > Moreover, if you consistently write a postfix variable next to the thing it is > related to, without space, then you cannot confuse it with a prefix function. > > c\p b <--- no space before => postfix > c -\p b <--- explicitely postfix, space is no problem > c \parenthesize b <--- verb with a space before => prefix function > c \mymusic b <--- a noun with a space before => a variable That's nice, but i think it will not help when there are multiple events/functions around notes. _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
