On 12/31/09 8:27 AM, "Han-Wen Nienhuys" <hanw...@gmail.com> wrote:
> On Thu, Dec 31, 2009 at 10:18 AM, Joe Neeman <joenee...@gmail.com> wrote:
>
>>>> If you were to use a context property, why would you need the special
>>>> command \overrideTimeSignatureSettings to change it? That is, why
>>>> couldn't people just use \set? If it helps, we could extend \set to
>>>> allow nested properties (the same thing that
>>>> http://codereview.appspot.com/182042/show does for paper-block
>>>> variables).
>>>
>>> Because I want to be able to \revert, not just \unset. I want to be able to
>>> change to some custom behavior, then go back to the default behavior without
>>> having to know what the default behavior is in detail.
>>>
>>> IIUC, \override is roughly equivalent to \set value (cons new-value
>>> old-value). I want to have that functionality, so that old-value is still
>>> available for a \revert.
>>>
>>> But certainly nested properties would help in making this change.
>>>
>>> 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.
>
> Of course, the \set \unset model falls apart for autoBeaming
> properties, which is exactly why have (had; do we still have it?) the
> hack that messes around with layout properties of a non-existent grob
> to store auto-beaming properties. I don't think having nice syntax
> for auto-beam settings is worth the effort and confusion of an
> implementation of stack-like behavior for normal properties.
No, we don't have that hack. That hack was eliminated in favor of a music
function to reset things.
>
> As a historical note: the stack model for grob properties started as a
> hack to make LilyPond usable on a poor musician's (no money to buy
> RAM) machine -
>
> http://www.mail-archive.com/gnu-music-disc...@gnu.org/msg03897.html
> http://www.mail-archive.com/gnu-music-disc...@gnu.org/msg03854.html
> http://www.mail-archive.com/gnu-music-disc...@gnu.org/msg03937.html
>
> We used to have a single namespace for properties, eg.
>
> \property stemVerticalDirection = #UP
>
> beyond hard to maintain the zillion properties, each override would be
> stored individually in every grob, taking an acons (16 bytes) per
> grob, per formatting property, which made Peter's machine start
> trashing
>
> git diff release/1.3.80..release/1.3.81
>
> shows the feature in all its endearing simplicity and naivity.
>
>> \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.
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.
Thanks,
Carl
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
