Re: Autobeaming

[Han-Wen Nienhuys]

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.

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.

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.


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