[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tweak, Override, Set
From: |
David Kastrup |
Subject: |
Re: Tweak, Override, Set |
Date: |
Sat, 05 Jun 2010 09:34:06 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
Carl Sorensen <address@hidden> writes:
> On 6/1/10 1:26 AM, "David Kastrup" <address@hidden> wrote:
>
>> Carl Sorensen <address@hidden> writes:
>>
>> Properties. There are tweaks, overrides, sets. Some of them work on
>> some properties, and there is no user level coherence to what you need
>> to do on what and why. Yes, I had some fits about that already, and
>> some people repeatedly told me I am an awful child for keeping up the
>> "why, why" questions and that things were just so. But I am arrogant
>> enough to say that something that can't be explained to me in a way that
>> I understand it is a mistake in a programmer interface. And we are
>> talking about a _user_ interface, one you can't avoid using.
>
> I can't answer the *why* question,
And that's bad for a user interface.
> but I can answer the what:
>
> 1) \set: Used to apply a setting that belongs to a context, and will in
> general affect all grobs in the context.
> \set properties agre generally established once per piece, and define
> how the context will respond throughout the piece.
>
> 2) \override: Used to modify the settings for a type of grob, to change the
> default behavior in the context. \override values apply to all grobs at a
> given moment in the named context. \override can apply from this time
> forward, or can be used with \once to apply only at a given time interval.
>
> 3) \tweak: Used to modify the appearance of a particular grob. This is used
> when \override won't work, because we don't want to affect all the grobs at
> that time step.
So you have three commands that, according to your description, all
affect grobs. Yet the sets of things you can use \set and \override on
are disjoint.
> Now, as to *why* we can't \override context properties, I don't know.
> I don't know if this is strictly a design decision, or if it's a
> technical limitation of some kind (although I can't imagine why it
> would be so).
I think it is sort of a glorified implementation artifact, raised to the
status of "design decision".
> I suspect that discussions about this topic constitute bikeshedding.
The problem is that it buys you bikeshedding for _every_ _new_ property
affecting a grob. You force a decision on the developer about what is a
slightly more useful classification for every single new property
affecting grobs.
That's a whole lot of bikesheds we are better off without. And the user
is better off without, since he has to check which shed his particular
property has been put in.
> Also, \set works on a hash-table (which is how context properties are
> stored) and \override works on an alist-chain (which is how grob
> properties are stored). The user shouldn't have to know these
> details, but that may be part of the why.
>
> I hope this has been a bit helpful,
You tell me how you manage to live with the distinction and philosophize
about it. Not why you'd want to.
--
David Kastrup
- Re: state of the release: the Good, the Bad, and the Ugly, David Kastrup, 2010/06/01
- Obstacles to LilyPond Development (was Re: state of the release: the Good, the Bad, and the Ugly), Carl Sorensen, 2010/06/01
- Tweak, Override, Set (was Re: state of the release: the Good, the Bad, and the Ugly), Carl Sorensen, 2010/06/01
- Re: Tweak, Override, Set,
David Kastrup <=