Re: Autobeaming

[David Kastrup]

Carl Sorensen <address@hidden> writes:

> On 12/31/09 5:18 AM, "Joe Neeman" <address@hidden> wrote:
>
>> I don't know the reason; I don't think I was even using LilyPond back
>> in the 2.0 days.  But it does sound perfectly reasonable to have
>> context (or translation, if you prefer) properties that can be
>> overridden and reverted.  I can have a look at adding this (if you
>> wouldn't rather have a go yourself).
>
> I'd love for you to have a look at it.  But be sure to get Han-Wen's
> approval.  AFAICS, it was Han-Wen's decision to make the change, for
> the two reasons I listed earlier.  And this would be undoing part of
> the change.

Yes it would.  We have had some previous discussion here, and the
current interface decision has not been explained satisfactorily in my
opinion.

We have for properties:

context: \set, \unset

grob: \override, \revert

There is nothing about the verbs "set" and "unset" which connects them
semantically with "context", and nothing about "override" and "revert"
which semantically connects them with "grob".

_If_ the distinction were important and inherently connected with
contexts and/or grobs, we should need

context: \contextset, \contextunset

grob: \grobset, \grobunset

This would make more sense to the user.  But \override and \revert also
have useful (and different) semantics and had them even before the
context/grob split was introduced.  So having \contextoverride and the
like would be nice.

I think it is reasonable (and Scheme-like) _not_ to have different
namespaces for contexts and grob, so that just \set, \unset, \revert,
\override do the trick for all.

But at least in _most_ cases context and grob should be distinguishable
by name, and even if we permit overloading, one could have accessors
called \set.context \set.grob and so on for that purpose.

The current distinction may or may not be done because of technical
details, but those details are not accessable to the average Lilypond
user.  I mean, I tried milking Han-Wen for the underlying reason and,
while getting a lot of information and causing a lot of aggravation and
work for him, I did not get anything out which would have made good
sense to me.

I may just be too stupid, but I doubt that the majority of Lilypond
users is much smarter in this particular aspect, and so it might be an
easier course to _abolish_ this difference again rather than _document_
it well enough so that even I and my ilk get it and feel confident
navigating Lilypond files based on that distinction.

-- 
David Kastrup