Re: Tweak, Override, Set

[David Kastrup]

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