Re: Crash with simultaneous-duplicating music function and \once\offset

[David Kastrup]

Aaron Hill <address@hidden> writes:

> On 2018-07-17 11:46, David Kastrup wrote:
>> Aaron Hill <address@hidden> writes:
>>> I tried manually duplicating the music:
>>>
>>> %%%%
>>>   \version "2.19.82"
>>>   music = { \once \offset length 5 Stem c'4 c'4 }
>>>   musicCopy = { \once \offset length 5 Stem c'4 c'4 }
>>>   \new Staff { c'4 << \music \musicCopy >> c'4 }
>>> %%%%
>>>
>>> This variant does compile, although the side-effect here is that the
>>> stem length is twice as long.
>>
>> As expected.
>
> Agreed.  Would this be worth documenting in some way, or is this just
> too contrived a scenario to care about?
>
>>> I suppose this would make sense providing simultaneous music results
>>> in a single stem shared by the notes so that the two \offsets stack
>>> their effects.  But then that doesn't explain why the same behavior
>>> isn't seen when omitting \once in the first example.
>>
>> Try with \temporary (though avoiding the crash with the same kind of
>> manual copy).  Without either \temporary or \once, any preceding
>> override (such as another \offset) is replaced, so you see only one
>> stem
>> length increase.
>
> With the underlying crash resolved, should we also expect the same
> behavior with the double \offsetting?  Again, as above, I am perfectly
> content with ignoring this if this is too esoteric.

Any override, not just \offset, will _remove_ one previous existing
override at the same context level.  Since other overrides don't refer
to "default values", you see this only after \revert: then you revert to
the state without the previous override (if any).  That's what
\temporary is for: \temporary \override ... \revert form a proper pair.

Note that this means that if you want to _retain_ the effect of a
previous override (including another \offset), you need to use
\temporary \offset .

This will and should not change.  It's part of the override system.

>> That one's the bug that my patch is supposed to, well, not fix but
>> lessen its consequences and giving a warning.  There is another one (a
>> failed assertion) that's still open.
>
> Sounds good.

Not really.  But I could not think about how to make this behave better
given the current infrastructure.  \offset uses a trick relying on
recognizing individual instances of it, so any non-music-function
definition containing \offset inside is not going to stack.

-- 
David Kastrup