Werner LEMBERG <[email protected]> writes: >> Well David, >> >> I should not want to let you implement this in the current form >> without any feedback from the developer list. [...] > > :-) > > Unfortunately, I have nothing useful to say.
Well, there is the code (obviously bound to be streamlined before implementation) and there are the proposed semantics. At least for the latter, I would want to get some sort of feedback. The semantics can be summarized as follows: a) a revert will only cancel the last _matching_ override, and the match includes the complete specified property path, _and_ the prospective use of \once. \revert will not cancel \once\override and vice versa. b) At the end of a timestep, all \once\override are reverted. All non-\once overrides remain in effect and on the stack as if none of the \once\override had ever happened. I have no clear view about \set yet. It would seem to me that \unset should be equivalent to \revert, and \set should be equivalent to \revert+\override. I am pretty sure that any less strict 1:1 matching of reverts and overrides will cause surprises to users that are really hard to track down and explain. This is a change of existing semantics and will likely require changes to some Lilypond scores. I should be quite surprised if such changes would not make the intent of the writer easier to follow and maintain, but they would be changes nevertheless. Once I rewrite the property code in C, getting negative feedback about the semantics afterwards will be a major pain. So I made a toy implementation (it is already suffering from too much premature optimization for a toy, but is still more or less readable) in Scheme. The version in C will be less readable, but deliver the same results. The Scheme version was likely overkill to do, but whether or not somebody actually looks at it, it helped for focussing on the needed data structures. So from those not interested in the code (long as it works(TM)), I'd be at least interested in hearing whether they would be ok with _what_ I propose it should be doing, never mind _how_ it does it. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
