I'm not sure this is the right way to go. Here's my reasoning:
a) Unifying the interface to context and grob properties seems to be a desirable long-term goal; at least several people have spoken in favour of it. But we do not yet have a proposal for doing this. In particular we do not have agreement about desirable syntax and semantics for modifying properties, although several suggestions have been made. b) The present semantics of \override are clearly deficient, as evidenced by the need for this patch, in that a proper stack of properties is required to avoid called functions changing the settings made by the caller. This is of minor importance now as few functions so that, but is likely to increase in importance as more complex functions are devised. c) The scope for writing music functions is now much greater thanks to sterling work by David K, and others are increasingly taking advantage of them. Functions are frequently posted on the user list in response to calls for aid. So whatever is implemented in response to (b) will inevitably filter into the user domain, and into the documentation. Achieving (a) is going to take a long time, so any solution to (b) which is introduced now will become established. d) The discussion on -devel about the several ways of approaching this issue has not yet come to a consensus. So rather than introduce this change into the code base now I would prefer to see more discussion and hopefully agreement on the best way of approaching (a), in particular what the optimum primitive operations should be. That will then inform this discussion about the best short-term step to take to resolve (b), as a means of facilitating progress towards (a), without the need at some stage to withdraw established facilities. Trevor http://codereview.appspot.com/6687044/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel