On 12/31/09 8:56 AM, "Han-Wen Nienhuys" <hanw...@gmail.com> wrote:
> On Thu, Dec 31, 2009 at 1:43 PM, Carl Sorensen <c_soren...@byu.edu> 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.
I'm not sure exactly what you mean by this.
>
> 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 .. )
Hmm -- I plan to do that. But I need to have per-Voice beaming rules, so I
think the rules need to be a context property.
And IIUC, the time signature properties are part of the Timing context, not
a Voice context.
>
> then you can be as flexible as you want. Are these settings
> intrinsically part of the music or part of the translation process?
The time signature is part of the music. The autobeaming is part of the
translation process, I think.
Do you think it's wrong to have the autobeam settings stored per context and
indexed by the time signature? If that's a bad decision, I'd like to get
that straightened out before I finish implementing the code.
Thanks,
Carl
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
