Re: Autobeaming

[Carl Sorensen]

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

> Carl Sorensen <address@hidden> writes:
> 
>> On 1/1/10 6:13 AM, "David Kastrup" <address@hidden> wrote:
>> 
>>> "Trevor Daniels" <address@hidden> writes:
>>> 
>>>> For varying time signatures changes could still
>>>> be made via \overrideTimeSignatureSettings.
>>> 
>>> I consider it a grave user interface mistake to have some things work
>>> only with \overrideTimeSignatureSettings, but not with \override
>>> timeSignatureSettings.
>>> 
>>> It is already bad enough that the completely arbitrary keyword/object
>>> relation override/revert->grob, set/unset->context is demanded from
>>> the user.  Now introducing artificial phrases that use the verb
>>> "override" for operating on a context property is really going off
>>> the deep end.
>> 
>> OK, point taken.  I'll come up with a different name for the music
>> function.  Do you have any suggestions?
>> 
>> How about \pushTimeSignatureSetting and \popTimeSignatureSetting?
> 
> Since we can have a push without a pop, that makes a somewhat
> uncomfortable pairing.

Why is this more uncomfortable than override without a revert?

> 
>>> Why have \overrideTimeSignatureSettings when timeSignatureSettings is
>>> not to be associated with "override"?
>> 
>> In my defense, it's because timeSignatureSettings is a special case of
>> a context property that wants \override and \revert behavior.
> 
> Which just goes to show that people associate the verbs "override" and
> "revert" with a particular behavior, not a particular property type.

Yes, that's true.  I don't think anybody has disagreed with that.

> 
> I don't think that I can offer better naming choices.  The problems you
> are trying to address right now are a straight consequence of tying
> override/revert names (and behavior) to grobs and set/unset to context
> properties.
> 
> I'd be perfectly fine with "In general, it is usually the best choice to
> set/unset context properties because ..., and to override/revert grob
> properties because ..."
> 
> And then one could mention in the descriptions of the exceptions "note
> that in spite of xxx being a yyy property, you would typically zzz it
> because ..."

Would you also be fine with "Context properties are only /set and /unset.
Grob properties are only changed with /override and /revert."?  That's the
current scheme, and that's all that's supported by the existing code base.
And I don't see much (if any) momentum for changing this, although you've
been trying to make it happen.

We would then have 

"timeSignatureDefaults is a context property, and thus can only use /set and
/unset to modify it.  Because we want to preserve pre-existing defaults, we
use special music functions instead of just using /set.
/overrideTimeSignatureDefaults adds a new setting in such a way that it can
be removed with /revertTimeSignatureDefaults.  Note that these music
functions are specific to the timeSignatureDefaults context property."

I don't see how this is dramatically different than what you propose above.

Thanks,

Carl