[Top][All Lists]

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

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

From: David Kastrup
Subject: Re: Crash with simultaneous-duplicating music function and \once\offset
Date: Tue, 17 Jul 2018 23:26:39 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

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

reply via email to

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