Re: Autobeaming

[Han-Wen Nienhuys]

On Thu, Dec 31, 2009 at 1:43 PM, Carl Sorensen <address@hidden> wrote:

>>>> Why have we decided that context properties can only be \set, and grob
>>>> properties can only be \overridden?  In version 2.0 we had two kinds of
>>>> properties, layout properties and translation properties.  I think that
>>>> translation properties in those days are what we now call context
>>>> properties, and that what were then called layout properties are now called
>>>> grob properties.  Also, in version 2.0 we could either \set (destructively
>>>> assign a value) or \override (push a value on the stack).  In fact,
>>>> according to the documentation, \override and \revert were the equivalent 
>>>> of
>>>> push and pop.
>>
>> This is a misconception, and the change in syntax was made to stop
>> this misconception from breeding.   There never was a stack-like
>> behavior for context/translation properties.   The suggested mechanism
>> for this instead was to have the default be at a higher level context
>> (eg. Score), and doing \unset at a lower level (eg. Staff) to restore
>> the default.
>
> OK.  When I was using 2.0 I didn't understand the internals well enough to
> appreciate these nuances.  But when I read the docs yesterday, they implied
> that /override and /revert applied to translation properties.

Well, the nuance is that \override do not strictly manipulate grob
properties (ie. per grob settings), but the alist containing the
defaults, and the alist is stored in a context property, so in a way
it applies to a context property.



>>> \unset is actually important for internally-used context properties.  So
>>> we would have to _add_ a revert function instead of just changing the
>>> behaviour of \unset.
>>
>> I think you are going at the problem from the wrong angle.  Are there
>> other cases that need this new behavior?  (I suspect not).  If not,
>> you should not implement something generic, but work on a more
>> palatable syntax for what we currently have through music functions or
>> some other existing extension mechanism.
>>
>
> That's actually what the current mechanism is.  It uses a special music
> function, and I can work within the current limitations.
>
> However, David was objecting to the special case that timeSignatureSettings
> would have as a revertable context property.  So I was trying to come up
> with a method that would not use it as a special case.

Right - but it is worth noting that we removed the revertable property
for the autobeam settings, exactly to not have the hack of doind
\revert/\override on something that is not a grob.

BTW, IIRC, we still have some special-case code for the hack to switch
off type-checking on the nested properties for the beam settings.

> Your feedback (which I'm happy to accept) is to go ahead and use it as a
> special case.  So I will.  And if we need to use it for another property in
> the future, then I guess we can turn the special case into a general case.
>
> Thanks for your feedback.  I'll proceed with the special case, and put some
> comments in the code indicating why we do it.

Looking back through the thread, I am wondering why you do not expand
these settings at the parsing stage, ie. have \time 2/4 expand to

 \set timeSigFraction = ..
 \set measureGrouping = ..
 #(set-auto-beaming .. )

then you can be as flexible as you want.  Are these settings
intrinsically part of the music or part of the translation process?

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen