Tweak, Override, Set (was Re: state of the release: the Good, the Bad, and the Ugly)

[Carl Sorensen]

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, 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.

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 suspect that discussions about this topic constitute bikeshedding.  I
suspect that patches that allowed \override to be applied to context
properties might be accepted.

As I wrote the previous paragraph, I think I finally got some clarity.  The
way \override is currently implemented is that a copy of the alist is made,
and then the new property is prepended, and the new alist is prepended to
the old alist-chain.  So if we were \overriding context properties, we'd
have very large alist-chains hanging around unnecessarily.

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,

Carl