Re: Autobeaming

[Carl Sorensen]

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

> Carl Sorensen <address@hidden> writes:
> 
>> On 1/1/10 10:27 AM, "David Kastrup" <address@hidden> wrote:
>> 
>>> Carl Sorensen <address@hidden> writes:
>>> 
>>>> 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.
> 
> The discussion around this times felt to me like an attempt of educating
> me to see this differently.
> 
>>> 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."?
> 
> Nope.  "Only" and "usually" are not the same.
> 
>> 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.
> 
> Yes it is.  Basically we have properties that can be set/unset, and
> properties that can be overriden/reverted.  And we have grob properties
> (with their defaults taken from the context apparently) and we have
> context properties.
> 
> The user is not interested about what is a grob property and what is a
> context property.  The user is interested about what properties can be
> set/unset, and what properties can be overriden/reverted.  And when
> there is the rare grob property which it makes more sense to set/unset,
> or the rare context property which it makes more sense to
> override/revert, it is stupid if you suddenly need accessor functions
> running everything into one word.
> 
> "Oh, this is a property which you want to override/revert, but because
> we classify it as a property which can't be overriden/reverted, you must
> not use \override xyZzy and \revert xyZzy but \overrideXyZzy and
> \revertXyZzy in order to override/revert it because we have decided that
> it belongs in a class that you don't override/revert, and so we fake
> overriding/reverting it by using words that the user might read
> correctly (though not writing them without reading and rereading the
> docs) even though Lilypond has no clue that we are actually taking it
> for a ride because it does not recognize the word parts
> "override/revert" in our compound music function names..."
> 
> That's stupid.  The user borderline is between set/unset vs
> override/revert (and there may even be cases where you want to use
> either), not between grob and context, so the user level information and
> interface should focus about what you can sensibly _do_ with the
> property, not whether it is grob or context.  The latter is an
> implementation detail, not a user level distinction.
> 
> If there is a reason to override/revert it, I want to be able use the
> respective keywords corresponding to that concept, and not be forced to
> use something which _resembles_ the keyword.

I know you want this.  I also know that, at least for now, you're not going
to get it.  I want to try to improve the auto beaming settings so LilyPond
can do the right thing.

I have received unambiguous guidance from Han-Wen that I should *not* add a
general capability for doing override/revert for context properties, even
though that's what you want to be able to do.

I've asked for suggestions for a music function name that would accomplish
the desired behavior for timeSignatureSettings.  You have given me no
suggestions.

I've proposed a couple of different names, both of which you have indicated
are unacceptable, and the only thing that is acceptable is to have \override
and \revert work for context properties.

If you want to have ay input on the syntax for the new music functions that
will be created in the near future, you need to give *constructive* feedback
on the syntax, rather than continue to express your displeasure over the
whole override/revert set/unset controversy.  Han-Wen has made his decision,
and I'm going to create a patch accordingly.  There will be a patch, and
there will be a music function name.  If your only comment is "don't do
this, fix it so you can use /override and /revert", then your comments will
be ignored.

Please not that I'm not trying to ignore you.  I'm just not going to go
against Han-Wen's decision.

Thanks,

Carl