lilypond-devel
[Top][All Lists]
Advanced

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

Re: [GLISS] differentiating pre/post/neutral commands


From: Janek Warchoł
Subject: Re: [GLISS] differentiating pre/post/neutral commands
Date: Mon, 3 Sep 2012 17:09:39 +0200

On Sat, Sep 1, 2012 at 10:09 PM, David Kastrup <address@hidden> 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
<address@hidden> 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.



reply via email to

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