Carl Sorensen <c_soren...@byu.edu> writes: > On 6/1/10 1:26 AM, "David Kastrup" <d...@gnu.org> wrote: > >> Carl Sorensen <c_soren...@byu.edu> writes: >> >> Properties. There are tweaks, overrides, sets. Some of them work on >> some properties, and there is no user level coherence to what you need >> to do on what and why. Yes, I had some fits about that already, and >> some people repeatedly told me I am an awful child for keeping up the >> "why, why" questions and that things were just so. But I am arrogant >> enough to say that something that can't be explained to me in a way that >> I understand it is a mistake in a programmer interface. And we are >> talking about a _user_ interface, one you can't avoid using. > > I can't answer the *why* question,
And that's bad for a user interface. > but I can answer the what: > > 1) \set: Used to apply a setting that belongs to a context, and will in > general affect all grobs in the context. > \set properties agre generally established once per piece, and define > how the context will respond throughout the piece. > > 2) \override: Used to modify the settings for a type of grob, to change the > default behavior in the context. \override values apply to all grobs at a > given moment in the named context. \override can apply from this time > forward, or can be used with \once to apply only at a given time interval. > > 3) \tweak: Used to modify the appearance of a particular grob. This is used > when \override won't work, because we don't want to affect all the grobs at > that time step. So you have three commands that, according to your description, all affect grobs. Yet the sets of things you can use \set and \override on are disjoint. > Now, as to *why* we can't \override context properties, I don't know. > I don't know if this is strictly a design decision, or if it's a > technical limitation of some kind (although I can't imagine why it > would be so). I think it is sort of a glorified implementation artifact, raised to the status of "design decision". > I suspect that discussions about this topic constitute bikeshedding. The problem is that it buys you bikeshedding for _every_ _new_ property affecting a grob. You force a decision on the developer about what is a slightly more useful classification for every single new property affecting grobs. That's a whole lot of bikesheds we are better off without. And the user is better off without, since he has to check which shed his particular property has been put in. > Also, \set works on a hash-table (which is how context properties are > stored) and \override works on an alist-chain (which is how grob > properties are stored). The user shouldn't have to know these > details, but that may be part of the why. > > I hope this has been a bit helpful, You tell me how you manage to live with the distinction and philosophize about it. Not why you'd want to. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
