Ok, this latest iteration is quite close to what I want to end up committing. All the work of picking apart articulations and events have gone into the rhythmic event iterator. What it does is to broadcast all articulations that have a listener, and keep the rest as articulations.
One side effect will be that things like c\3 will exhibit a string number (previously, only <c\3> did). Another side effect is that tweaks can work on single notes outside of chords even when those have non-articulation postevents. You get an EventChord iff you write < ... >. A note getting postevents always receives them in 'articulations, whether it is part of an EventChord or not. Postevents on a chord get appended to the EventChord members as previously. This is total straightforward. I have _removed_ the compatibility option since it a) considerably complicated code, grammar and semantics b) was not able to a reasonably reliable job Instead, it will make sense to write a music function that tacks EventChord around naked rhythmic events (unwrapping the articulations in the process) and use that manually for converting music expressions to the old style when one does not want to adjust one's internals. In spite of the remaining problems with spanners and trills (slated to be removed in the next days), this should be good for testing how hand-written analysis code fares. There should be no difference to the way synthesized code (in the old style) gets typeset. So give this a testing now or after I shook out the last bugs. I am really planning to get this into 2.16. http://codereview.appspot.com/5440084/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel