lilypond-devel
[Top][All Lists]
Advanced

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

Re: Naming _another_ lacking puzzle piece


From: David Kastrup
Subject: Re: Naming _another_ lacking puzzle piece
Date: Sun, 14 Oct 2012 14:19:29 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

"Trevor Daniels" <address@hidden> writes:

> A. 
> \override does a pop/push
> \revert does a pop
> \temporary\override does a push.
>
> so \temporary\override and \revert are a matching pair.

More importantly: on an empty stack, any number of \override followed by
\revert are a matching "pair".

> B
> \override does a push
> \revert does a pop
> \clear restores the stack to the default state.
>
> so \override and \revert are a matching pair.
>
> Both of these are essentially equivalent, except A does not have a stack
> clear operation, but which of these is the clearer, and which the more 
> intuitive?

You are viewing this from the "stack" angle.  But that is a complex
view already.  The actual user view is

A.
\override sets a context-specific property value
\revert removes a context-specific property value
This works reliably.  If I ever need more complex stuff than that, I can
look it up.

And to make the "this works reliably" part work, we won't expose any
isolated \temporary \override without matching \revert in LilyPond.

People have complained about \push/\pop being intolerably
programmer-centric _terminology_, but terminology is cheap.  The
underlying fear was "people won't understand what push/pop does", and
that can't be cured by using prettier names but only by not doing
anything hard to understand unless asked for it.

Yes, this makes it slightly more tricky to understand the stack mode of
operations.  But it will make it much easier to just ignore that view of
things completely.

LilyPond is _complex_, and sometimes one needs that complexity.  But we
should try to keep simple things simple, and leave the need to
understand complex behavior for when complex things are required.

-- 
David Kastrup



reply via email to

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