All of this is absolutely devastatingly horrible code that is not reconcilable with sane per-session semantics and tampers with LilyPond internals in a way that has bleed-over effects into future files in the same command line.
In addition, the interfaces into the exposed internals are absolutely horrific and cryptic and don't make any sense as a user interface. This is taking everything that is broken with input/regression/scheme-text-spanner.ly, magnifies it to a number of other cases, and gives it a bad interface. No, no, and no again. Extensibility in this area would be nice, but pulling out LilyPond's innards into the public without a proper design is no substitute for that and totally a step in the wrong direction. None of these ad-hoc interfaces can sensibly be guaranteed to survive any evolution of LilyPond's operation since they don't interface to functionality, but rather to the current internals. If people want to poke LilyPond's internals with a stick, of course they can do so with all bad side effects including everything breaking possibly on the next update. But there is no point giving them a stick with a handle for that if there is no way in which we can guarantee the handle working for longer or better than the stick does. https://codereview.appspot.com/7009047/diff/2001/ly/property-init.ly File ly/property-init.ly (right): https://codereview.appspot.com/7009047/diff/2001/ly/property-init.ly#newcode682 ly/property-init.ly:682: defineEventClass = Absolutely awful interface here. No. https://codereview.appspot.com/7009047/diff/2001/scm/define-grobs.scm File scm/define-grobs.scm (right): https://codereview.appspot.com/7009047/diff/2001/scm/define-grobs.scm#newcode2695 scm/define-grobs.scm:2695: (define (register-grob-name x) No. This is an interface with heavy session bleedover characteristics: as long as a symbol is not garbage-collected (for example, because it is referenced anywhere as a symbol in a totally non-grob context), it will remain defined between sessions. First the internals need to be redefined in a manner allowing for sane per-session behavior before any exposed public interface is offered for that. https://codereview.appspot.com/7009047/diff/2001/scm/define-grobs.scm#newcode2703 scm/define-grobs.scm:2703: (completize-grob-entry x)) No, this will cause heavy bleedover effects between sessions. https://codereview.appspot.com/7009047/diff/2001/scm/define-music-types.scm File scm/define-music-types.scm (right): https://codereview.appspot.com/7009047/diff/2001/scm/define-music-types.scm#newcode758 scm/define-music-types.scm:758: (define-public (make-music-descriptions descriptions) Unsuitable for a public interface because of session bleedover. https://codereview.appspot.com/7009047/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
