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 22:26:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Joe Neeman <address@hidden> writes:

> On Sun, Oct 14, 2012 at 5:19 AM, David Kastrup <address@hidden> wrote:
>
>     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.
>
> How do you plan to achieve this? If there are any commands using a
> \temporary...\revert that spans for more than one timestep, I can
> always nest them and I can always sneak in \overrides between the
> \temporary and the \revert, just by putting music in parallel.

"Sneaking" is expected to cause problems, and sneaking in _overrides_ is
not problematic as they just change the _top_ of the stack, and that
gets reverted anyway.  Only sneaking in _reverts_ destroys the stack
balance, and that means that some states get reverted _more_ than
appropriate.  However, if the expectation of the user is that they get
reverted _totally_ when he writes reverts, things end up better than
expected.

>     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.
>
> I think stacks are easy to understand, even for non-technical users.
> The reason for avoiding push/pop is just to stop people from thinking
> "oh, that's programming, it must be hard." 

Having to keep a stack properly nested _is_ a nuisance.  The fundamental
complaint about Scheme as the core programming language of LilyPond is
that you need to keep so many parentheses nested.

>     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.
>
> While that's true, I think that a coherent and consistent whole is
> more important than a slightly simpler beginner interface.

I don't find the user interface, as it is, inconsistent.  One rarely
needs to bother with the full power of a stack (heck, we got along
7 years without a hook into push), and the non-pushing default of
\override reflects that.

-- 
David Kastrup



reply via email to

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