Hi all,
@David: thank you for your "emergency call"!
@Nathan: sorry, for giving you bad advise in this case!
To summarize, what to do with spanners, tagged with an ID: Use context
properties to store them "globally". You can consider the Score context
"global". If there is a context defined with \=Staff.myid, store it in a
context property of - in this case - the Staff context.
Whenever you are up to using static members, change it to properties of the
Score context - or look for session global objects.
Cheers
Jan-Peter
Am 24. Juni 2016 16:22:30 MESZ, schrieb David Kastrup <d...@gnu.org>:
>Jan-Peter Voigt <jp.vo...@gmx.de> writes:
>
>> Hi Nathan, hi Dan,
>>
>> the "nearest" context might be on Staff level - or, if (for example)
>> you have voices switching staves, on StaffGroup level, where a
>> StaffGroup also might be a GrandStaff or the like. If the context
>> property turns out to complex (I don't see all consequences yet),
>> you'll have to use this static engraver member. But you should try
>the
>> "nearest" context.
>
>A static engraver member would be a total disaster. What happens for
>stuff like
>
>{ c1-\markup \score { \new Staff { e1 } } }
>
>with global variables like that? What happens when the engraver is
>being collected but the static member stays around without protection
>from garbage collection? Or if it is protected, will it drag into the
>next file to be processed on the command line?
>
>Ids for \= could be specified as a key-list? and if it has two members
>(more would be an error) the first should be a context type symbol
>indicating the context the separate engravers choose to share their
>data
>over.
>
>--
>David Kastrup
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
