Joe Neeman <joenee...@gmail.com> writes: > On Sat, 2009-11-21 at 17:22 +0100, David Kastrup wrote: >> There is a chapter "set vs override" in the manual. >> >> I am afraid that I fail to grasp the difference from the chapter.
[...] >> If the element description is a _special_ type of context property, >> that would imply that there is just _one_ different kind of >> properties. It completely fails to mention _what_ makes the element >> descriptions special and not settable with \set. >> >> These properties are named in `StudlyCaps' (starting with capital >> letters). They contain the `default settings' for said graphical >> object as an association list. See `scm/define-grobs.scm' to see >> what kind of settings there are. Element descriptions may be >> modified with `\override'. >> >> So why can't we use \set with element descriptions? And where is the >> difference to context properties changing values? After all, the >> principal purpose of \override is also to change the value, and >> \once\override very obviously changes behavior over time while >> interpreting music. > > Since \override works by modifying special context properties, you can > actually use \set for setting grob properties. However, \override > does some extra useful work: for a start, it appends new overrides to > a list of overrides for a grob so that they can be easily reverted > (\set just clobbers the existing variable). Also, \override supports > nested properties (useful for things like 'bound-details). The > type-checking mechanisms are also different for \override and \set. You describe different semantics for \set and \override. Then you describe different restrictions. And then you say that they have different type-checking mechanisms. The problem is that the different type-checking mechanisms are there for the two different kinds of properties, but the whole thing appears completely arbitrary: it is not clear why you would want to permit one kind of command just with one set of properties, and the other with the other. I see no connection between the type of command you should use and the kind of properties that are affected. If you take a look at a recent proposal <URL:http://codereview.appspot.com/152127/patch/1004/5>, \tweak (another setter) is proposed to support nested properties. I don't see a good rationale why \set, \override, \revert, \tweak should not work on the same set of properties (including subproperties). I don't see an explanation why it makes sense to differentiate between them. And I am arrogant enough to believe that if I don't understand a design decision after a few days of trying, it is likely that ultimately a lot of people other than myself will be better off if the distinction gets abolished. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
