lilypond-devel
[Top][All Lists]
Advanced

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

Re: [GSoC] spanners project update


From: David Kastrup
Subject: Re: [GSoC] spanners project update
Date: Wed, 06 Jul 2016 12:00:32 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Nathan Chou <address@hidden> writes:

> On Tue, Jul 5, 2016 at 1:54 AM, David Kastrup <address@hidden> wrote:
>> Nathan Chou <address@hidden> 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



reply via email to

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