Carl Sorensen <c_soren...@byu.edu> writes: > On 1/1/10 6:13 AM, "David Kastrup" <d...@gnu.org> wrote: > >> "Trevor Daniels" <t.dani...@treda.co.uk> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
