David Kastrup <d...@gnu.org> writes:
> David Kastrup <d...@gnu.org> writes:
>
>> Thomas Morley <thomasmorle...@gmail.com> writes:
>>
>>> Hi,
>>>
>>> I stumbled across
>>> (equal? #{ \voiceOne #} voiceOne)
>>> returning false.
>>>
>>> Is it expected behaviour?
>>
>> equal? is not implemented all that great for "probs" but Music::equal_p
>> is implemented in a manner where at least
>>
>> #(display (equal? voiceOne (ly:music-deep-copy voiceOne)))
>>
>> would be expected to display #t and it doesn't.
>>
>> Sigh. I'll see what I can find out.
>
> Tracker issue: 5391 (https://sourceforge.net/p/testlilyissues/issues/5391/)
> Rietveld issue: 363740043 (https://codereview.appspot.com/363740043)
> Issue description:
> Prob::equal_p: discard "origin" property Previously elements of
> class Input was considered equal when compared as part of Music
> property lists but this did not take into account that some music
> might store its origin (if any) at different locations in its
> property lists. So we just discard any "origin" property
> completely, regardless of position in the property list and its
> actual value type. Also contains commit: Don't set origin on
> copied music explicitly There would be some mild incentive if the
> origin were accessed an inordinary amount of times (and thus leaving
> it unset would maximize access times to it) but there is no evidence
> for that. One reason might be to ensure greater structural
> similarity between copies of music, but Prob::equal_p has been
> changed to be robust against differences here.
In the mean time, here is a workaround:
voiceOne = \voiceOne
Seriously.
--
David Kastrup
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
