The commit mentioned in the subject line is just not right. The purpose of a definition like "define-event-class" is not, as far as I am concerned, to provide an attack vector where one can, given suitable ingenuity, hack together code that fiddles with internals to the effect of defining an event class, bypassing all the code intended for that purpose in Lilypond.
The purpose should be to make it feasible to define an event class. If the regtest has to hack together its own `add-grob-definition' function doing extensive surgery on internals, that goal is not met. The regtest should be accessible to a lower breed of humans than the programmers of the core functionality. In order to avoid a maintenance nightmare, it should preferably be using the same interfaces as the Lilypond core. Now the Lilypond core currently uses the interface "make the programmer create a giant list in one central place that is already sorted and prefilled with hand-crafted entries". Tell you what? I think that most (likely all) of these scm/define-*.scm should be obliterated. Instead, the relative entries should be generated by appropriate user-accessible commands like `define-event-class' near the place that the event classes are actually used. They can record the defining location for the purpose of cross referencing generation. Ok, enough ramblings. While not all of this needs to be implemented right away, the current definition of `define-event-class' is clearly insufficient if a not completely trivial usage example (what the regtest is) requires lots of additional internal surgery. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
