Re: Autobeaming

[Carl Sorensen]

On 12/31/09 8:27 AM, "Han-Wen Nienhuys" <address@hidden> wrote:

> On Thu, Dec 31, 2009 at 10:18 AM, Joe Neeman <address@hidden> 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/address@hidden/msg03897.html
>  http://www.mail-archive.com/address@hidden/msg03854.html
>  http://www.mail-archive.com/address@hidden/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