[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Autobeaming
From: |
Carl Sorensen |
Subject: |
Re: Autobeaming |
Date: |
Fri, 1 Jan 2010 16:35:16 -0700 |
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
Re: Autobeaming, Graham Percival, 2010/01/01