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. 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/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. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
