Two years ago, David and I had a discussion about the existence of /tweak, /set, and /override. David pointed out the confusing nature of the different ways of changing properties, and the difficulty of explaining this to the user.
<http://lists.gnu.org/archive/html/lilypond-devel/2010-06/msg00054.html> Perhaps now David has put together enough infrastructure that it is time to abandon the previous interface and replace it with one that will be more consistent to the user. IIUC, /set and /unset are currently the same as /override and /revert, except they apply to different things: /set and /unset to context properties, and /override and /revert to grob properties. But David has done such good work in allowing the system to determine the target of a call (I suspect that with David's recent patches we have the infrastructure to apply the same call to both context properties and grob properties) that I believe we can drop the distinction. If I'm wrong, please correct me, David. Would it be possible to move to something like the following? /set modifies a property in such a way that no history is kept. /unset (or /reset) returns a property to its default value. /override modifies a property in such a way that a history of the change is stored. /revert undoes the most recent /override of the specified property. /oneMoment (equivalent to /once, but perhaps a more clear name) modifies a property in the current context for one musical moment. Once the musical moment has passed, the changes introduced by the /oneMoment evaporate. We could apply /oneMoment as a modifier to either /set or /override, or we could just allow it to stand on its own. There is no difference between /oneMoment /set and /oneMoment /override, since the changes evaporate once the moment is gone, so we might as well just to /oneMoment, I think. /oneGrob modifies a property for a single grob (equivalent to /tweak). Its effects are limited to a single graphical object, rather than all objects occurring in this context at this time. If we want to move in this direction, I think now is the time to do it (before /temporary gets into the code base). The reason I believe we should do it now is that without /temporary available, convert-ly rules could move all /override to /set and all /revert to /unset or /reset. We don't need to try to parse the /temporary and track the items to which the /revert applies. Thanks, Carl _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel