Han-Wen Nienhuys <hanw...@gmail.com> writes: > 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.
It didn't succeed. I think that in this case it would make more sense to better match the behavior to the misconception than the other way round. Because understanding the misconception requires technical expertise on the level required for _changing_ the behavior, and that is a scarce resource. If yielding to this misconception needs two different _implementations_ of the setting commands depending on whether they are used in contexts or grobs that is a smaller price to pay than requiring two different user level _explanations_. If you can save yourself the trouble of making your _users_ smarter by instead making the _code_ smarter, that is well-invested time. Because user stupidity is diversified and unreliable, whereas code needs to be fixed just once. > 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. But the confusion _is_ there. The documentation cannot really hope to clear it up because there is no reason accessible from user-level for it. > 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 So now instead of Peter's _machine_ thrashing while typesetting music, we have Paul, George and Mary (and likely Peter as well) thrashing while trying to understand the documentation. That's not a good deal. Especially because implementing grob and context properties differently does not necessitate giving them a different user interface. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
