lilypond-user
[Top][All Lists]
Advanced

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

Re: modular "markup" and arguments


From: David Kastrup
Subject: Re: modular "markup" and arguments
Date: Wed, 06 Nov 2013 10:23:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Johan Vromans <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> Correct.  In stack terms, \revert is a "pop" while "\override" is "pop,
>> push" (each context has its own stack).  In contrast,
>> "\temporary\override" is just "push".  So a sequence of
>
> So we have, for context properties:
>
> \set                    set prop to value
> \unset                  set prop to default value
> \once\set               set prop for next operation, then fall back
>                         to current value
>
> For grob properties:
>
> \override               pop + push value for prop
> \temporary\override     push value for prop
> \revert                 pop value for prop
> \once\override          set (push?) grob prop for next operation, then
>                         fall back (pop?) to current value
>
> Unfortunately, the relevant documentation page
> http://lilypond.org/doc/v2.17/Documentation/notation/set-versus-override
> is a bit, eh, empty...

Uh, I'm pretty sure I wrote a rather carefully phrased treatise about
this in general.  But I have to admit I can't find it at minute's
notice.  And git log --grep override Documentation does not turn up
anything relevant.  Did I dream this?

> As a musical programmer (programming musician) I would really appreciate
> a much simpler push/pop/clear approach, with no distinction between
> context and grob properties. Even a \with would be a step forward:
>
>   \with property = value { ... }
>
> (not complaints, just thoughts)

There are not going to be any substantial changes before LilyPond has
moved to GUILE2 and the property system has been rewritten.  At the
current pace of development, that's probably material for 2.24 at the
earliest unless my funding dries up before that.

-- 
David Kastrup




reply via email to

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