Re: Autobeaming

[David Kastrup]

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.

-- 
David Kastrup