Re: Autobeaming

[Carl Sorensen]

On 12/31/09 5:18 AM, "Joe Neeman" <address@hidden> wrote:

> On Tue, 2009-12-29 at 15:48 -0700, Carl Sorensen wrote:
>> On 12/29/09 2:14 PM, "Joe Neeman" <address@hidden> wrote:
>>> I much prefer leaving it as a context property. Grob properties of the
>>> TimeSignature grob should be things that affect the appearance of the
>>> TimeSignature grob, not the creation of beams.
>>> 
>>> 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.
> 
> 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.

Thanks,

Carl