Re: Tweak, Override, Set

[Carl Sorensen]

On 6/5/10 1:34 AM, "David Kastrup" <address@hidden> wrote:

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

Perhaps.  There are lots of user interfaces I use regularly that I don't
understand the "why" behind them.  As long as I know the "what", I can make
it work.

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

Yes, but they are relatively easy for me as a user to determine which is
which.  The \set things are found in the Internals Reference under Contexts
and Tunable Context Properties.  The \override things are found under All
Layout Objects, Graphical Object Interfaces, and User Backend Properties.

Observing this distinction in the Internals Reference has caused me to see
another distinction (to which Han-Wen has alluded in the past, but I haven't
grasped it).  Context properties are used and accessed during the
translation stage.  Grob properties are used and accessed during the output
stage.
> 
>> 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".

Perhaps.  You now have commit access, and can explore whatever you want on
the dak branch.  If you can demonstrate that the distinction between \set
and \override can be eliminated, and that there is no significant price to
pay (in terms of memory or time) for eliminating the distinction, then I'd
be willing to help push for eliminating the distinction.

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

Perhaps.  I haven't felt the need to have such a discussion when doing fret
diagrams.  I have had some of those discussions when working with Thomas
Morgan on Chord Names.

And there are two ways to avoid the discussion on new properties.  One is to
eliminate the distinction between Grob and Context properties.  The other is
to document the selection process so that the developer can make a rational
choice.

>> 
>> I hope this has been a bit helpful,
> 
> You tell me how you manage to live with the distinction and philosophize
> about it.  

I'm sorry I wasted your time "philosophizing" about it.  I was doing my best
to explain the situation as I understood it.  If you'd rather I not do so,
just let me know.

> Not why you'd want to.

Because it takes me much less time to learn to work with the existing system
than to try to change it.  And I can get the results I want working within
the system.

If the existing system is giving you problems in working with your accordion
diagrams, then I'd suggest you raise a discussion about the problems you're
having with your accordion diagrams.  We've already identified one new
context property (TimeSignatureSettings) that would benefit from having
\override functionality.  If you have another context property for Accordion
diagrams that should have \override functionality, then we'd have two, and
there would be a specific reason for requesting the use of \override on
general context properties.  In short, I think a specific argument is much
more likely to carry weight here than a general argument.

Thanks,

Carl