Thomas Morley <thomasmorle...@googlemail.com> writes: > It was a copy/paste-error. Actually, I don't want to define a new > grob, only new properties. > > The foolowing seems to be ok, or not? > > \version "2.15.38" > > #(define (define-grob-property symbol type? description) > (if (not (equal? (object-property symbol 'backend-doc) #f)) > (ly:error (_ "symbol ~S redefined") symbol)) > > (set-object-property! symbol 'backend-type? type?) > (set-object-property! symbol 'backend-doc description) > symbol)
Mostly harmless. It puts object-properties on symbols, and symbols are global entities IIRC (their bindings/variables are module-local in contrast). So depending on whether the symbol gets garbage-collected between files or not (depends on whether this particular symbol is used for any purpose anywhere in the global code or variables), behavior might differ, in that you might or might not get complaints when using this property without defining it. But that is a design mistake you can't really avoid with reasonable effort, and the worst that can happen is that you get unexpected undefined behavior instead of an error message/warning. > #(map > (lambda (x) > (apply define-grob-property x)) > `( > (marker ,symbol? "Marker in grob for function-call") > )) No point in using map when throwing the result away. Use for-each instead. > \relative c' { > c1 > \override Staff.BarLine #'after-line-breaking = > #(lambda (grob) > (let ((xy (ly:grob-property grob 'marker))) > (newline)(display xy))) > d > \override Staff.BarLine #'marker = #'foo > e > } At some point of time, LilyPond may become unhappy when setting properties that are not in any interface or grob definition. But then it will probably also get a proper API for defining such things, and so one can leave off worrying until then. This code is depending on internals of LilyPond, but it is at least not overwriting them. If the internals or interfaces changes, it will break, and there will be no convert-ly migration for it. At the current point of time, you cannot do better. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user