Graham Percival <[email protected]> writes: > On Sun, Aug 14, 2011 at 05:31:11PM +0200, David Kastrup wrote: >> Werner LEMBERG <[email protected]> writes: >> >> > 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. > > I agree. :( > >> The semantics can be summarized as follows: > > Those look fine to me.
There are likely two contentious changes. The first is related to nested properties: namely that the pairing of override/revert of a property x should be independent from override/revert of a nested property x.y. However, if overrides and reverts of x and x.y are not acting as if they were issued independently, and if overrides and reverts of x and x.z are not acting as if issued independently, then it gets quite hard to let overrides and reverts of x.y and x.z act as if they were issued independently. And that would make working with nested properties less straightforward in my opinion. The second is that \once\override will not mix with \override\revert. Currently \once\override ... \override will have the second \override active just for the current timestep, and revert to the previous value afterwards. \override ... \once \override ... \revert \revert will at first revert both overrides, but reinstate the state after the first override at the end of the timestep. If I understand the code correctly. I prefer to have behavior corresponding to simple well-defined rules rather than implementation artifacts. Even if it means that the implementation is harder to write. >> 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. > > If you really want to poke the hornet's nest, and if the scheme > implementation can be used for any arbitrary lilypond file (i.e. > just by adding an \include "new-overrides.ly" to the top), then we > could ask on the lilypond-user mailing list. Since a number of other Context internals in addition to the grob property list manipulators themselves are written in C++, such a replacement is unfortunately not feasible to do without recompilation as far as I can see. > Since we'll be having a release candidate as soon as Mike fixes > his python 2.4 problem in output-distance.py, I'd ask you to wait > until 2.16 is out before pushing this change. That's the only > real feedback I can give, sorry. I'll not likely be that fast, anyway. On the other hand, once the stuff works for me, it seems reasonable to get it out for massive testing. So it seems a bit awkward that we don't have a release branch separate from master. Since the change of semantics would not be limited to nested properties, it does not make sense to rush this in under the pretense of it being a mere bug fix, however. It is more like fixing a design flaw. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
