[Top][All Lists]
[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
- Re: Naming _another_ lacking puzzle piece, (continued)
- Re: Naming _another_ lacking puzzle piece, David Kastrup, 2012/10/14
- Re: Naming _another_ lacking puzzle piece, Trevor Daniels, 2012/10/14
- Re: Naming _another_ lacking puzzle piece, David Kastrup, 2012/10/14
- Re: Naming _another_ lacking puzzle piece, Trevor Daniels, 2012/10/14
- Re: Naming _another_ lacking puzzle piece, David Kastrup, 2012/10/14
- Re: Naming _another_ lacking puzzle piece, Carl Sorensen, 2012/10/14
- Re: Naming _another_ lacking puzzle piece, David Kastrup, 2012/10/14
- Re: Naming _another_ lacking puzzle piece, Phil Holmes, 2012/10/14
- Re: Naming _another_ lacking puzzle piece, Janek Warchoł, 2012/10/15
- Re: Naming _another_ lacking puzzle piece, Joe Neeman, 2012/10/14
- Re: Naming _another_ lacking puzzle piece,
David Kastrup <=
- Re: Naming _another_ lacking puzzle piece, Joe Neeman, 2012/10/16
- Re: Naming _another_ lacking puzzle piece, David Kastrup, 2012/10/16
- Re: Naming _another_ lacking puzzle piece, Joe Neeman, 2012/10/16
- Re: Naming _another_ lacking puzzle piece, Joe Neeman, 2012/10/16
- Re: Naming _another_ lacking puzzle piece, David Kastrup, 2012/10/14
- Re: Naming _another_ lacking puzzle piece, Reinhold Kainhofer, 2012/10/13
- Re: Naming _another_ lacking puzzle piece, Werner LEMBERG, 2012/10/13
Re: Naming _another_ lacking puzzle piece, Trevor Daniels, 2012/10/13