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: David Kastrup
Subject: Re: [GLISS] differentiating pre/post/neutral commands
Date: Mon, 03 Sep 2012 17:24:19 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Janek Warchoł <address@hidden> writes:

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

\times has become a music function while maintaining its syntax.  \time
has become a music function, integrating some form of compound time
command that had previously required spelling out the time fraction in
Lisp form.  \key has become a music function, including the possibility
of writing \key\default.  \mark has similarly become a music function,
including writing \mark\default.

If you want to have something with a similar syntax to all those
preexisting commands, you can write it yourself.  If you want to replace
one of those commands with a personal modification, you can (since they
no longer are reserved words).

As a result, there is less pressure to discuss syntax additions for that
kind of thing.

\tweak got an optional grob argument looking just like it had been
always there.  This did not require parser discussions or changes.

-- 
David Kastrup




reply via email to

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