lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Thomas Morley
Subject: Re: How to catch the current height of a StaffGroup?
Date: Wed, 23 May 2012 22:27:14 +0200

2012/5/23 David Kastrup <address@hidden>:
> 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

Thanks for your         explanations. Hopefully my mind is clearer now. :)

-Harm



reply via email to

[Prev in Thread] Current Thread [Next in Thread]