Nathan Chou <starry...@gmail.com> writes: > On Tue, Jul 5, 2016 at 1:54 AM, David Kastrup <d...@gnu.org> wrote: >> Nathan Chou <starry...@gmail.com> writes: >>> That is a good point; I might agree with spanner id's not being shared >>> across voices if nothing has been indicated. To make this less >>> tedious, however: what if after the parent context in which to share >>> spanners has been given once, future spanner id's (in the same voice) >>> default to share in that context? Or alternatively, perhaps this >>> parent share context could be set as a context property, allowing the >>> user to indicate a "default"? >> >> How often are you expected to write this? > > If I understand correctly, my idea was that after you write the shared > parent context *once*, future cross-voice spanners in that voice would > by default share in that context; or alternatively, the shared parent > context would be set *once* as a context property.
My question rather was "how often are you expected to use cross-voice spanners that the savings would be worth the trouble?". We don't use a similar address-saving technique for, say, \override. > Although I am now having doubts since it does make sense for the > default blank spanner id (i.e. when no id is given) to not be shared > across voices, regardless of the presence of cross voice spanners. For > now I will never share spanner ids unless the context is indicated > with \=. I think that's sanest. > I am currently working on warnings for unterminated spanners. However, > when I lookup the context property to identify such spanners, and that > property was never set, Context::internal_get_property attempts to > look in higher contexts, which sometimes causes warnings for contexts > that have not actually ended. Does adding an optional argument to > internal_get_property to prevent looking in higher contexts seem > reasonable? Anything wrong with Context::here_defined ? -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
