Am 01.07.2016 um 09:21 schrieb Urs Liska:
Am 01.07.2016 um 09:01 schrieb Nathan Chou:
Thanks David and Urs for replying.
There is a detail I would like to clarify. David suggested allowing \=
to optionally specify the parent context in which a cross-voice
spanner's information is shared (although I am not sure how that would
be done with a key-list, since I think the spanner id itself is a
string).
Right. Maybe it should rather be a key? That would also make
comparison generally faster than string comparisons.
Would I convert a string input to a key, or should I only accept a key
as a valid id? The latter seems more convenient but I imagine would
break backward compatibility.
Backward compatibility is not always a requirement. If a convert-ly rule
can be written for the change then it isn't an issue at all.
If this context is not specified, should it default to Score or Staff
(or something else)?
Nothing at all? Namely don't look anywhere else unless asked for?
So cross voice spanners should only work if the context to share
information is specified, right? If the context is not specified and
there is no default, the spanner id would only be used within the same
voice and not made known to any other contexts.
Hm. If this is a limitation required by the implementation then it's
acceptable. But from a user perspective I would be very surprised if an
ID isn't recognized without an explicitly named context around it. Isn't
that the (one) idea of an ID in general, defining an ID and have it
addressable from anywhere?
Well, the spanner-id is used right now to have multiple slurs (or other
spanners) in the same Voice. So keeping the spanner-ids in the current
Voice would only preserve the current behaviour, if no other context is
given. But OTOH (IISC) it wouldn't break the current implementation, as
long, as IDs are Score-unique and not only Voice-unique. My preference
would be to place it in the Score-context.
Jan-Peter
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
