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. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user