It took me until reading the commit message to figure out that this is actually meddling with the parser. I really should do more reviewing.
It might have made sense to put the parser part, which appears reasonably independent, into a separate issue to make it more visible. The parser is notably tricky, and there are a lot of things where one can go wrong with juggling music expressions. Not that it appears that you did. There is, however, one restriction that does not appear to serve any purpose apart from being a restriction. https://codereview.appspot.com/26470047/diff/70001/lily/parser.yy File lily/parser.yy (right): https://codereview.appspot.com/26470047/diff/70001/lily/parser.yy#newcode2821 lily/parser.yy:2821: } else if (ly_prob_type_p (s, ly_symbol2scm ("ArticulationEvent"))) { I think there is no point in restricting the type to an ArticulationEvent. Just use a check for it being music and is_mus_type ("post-event") here. Supporting event functions as well (similar to how shorthands like |, (, ), and so on work) would be a nice gesture, but I don't see a nice scheme for that right now. https://codereview.appspot.com/26470047/ _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
