Re: Autobeaming

[David Kastrup]

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

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

-- 
David Kastrup