Re: How to catch the current height of a StaffGroup?

[David Kastrup]

Thomas Morley <address@hidden> 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