Simon Albrecht <[email protected]> writes: > In a large project I ran into the following problem: If I define and > call a function in Scheme-only syntax, \removeWithTag will ‘bleed > over’ to following expressions (don’t ask me how exactly, I’m only > guessing…). > Consider the following dummy example: > > %%%%%%%%%%%%%%%%%% > \version "2.19.35" > > test = { 1-\tag not-vl -"it works!" } > > #(define (build-part mus) (make-sequential-music (list mus))) > % no problem with > %#(define (build-part mus) #{ { $mus } #}) > > vl = > \removeWithTag not-vl > #(build-part test) > % no problem with > %\build-part \test > > tbn = > #(build-part test) > > \score { > \tbn > } > %%%%%%%%%%%%%%%% > > The TextScript should be displayed, but it isn’t. It works with either > of the commented alternatives, i.e. those involving the LilyPond > parser. I’d be very much interested in the reason for this. It seems > like an inconsistency that should be fixed.
Don't reuse music expressions in different contexts without _copying_ them. $mus creates a copy. \test creates a copy. #test does not create a copy. Use ly:music-deep-copy or music-clone for getting the equivalent of \test. Many of LilyPond's music manipulating functions are _destructive_ in order to allow for incremental manipulation of large/growing music expressions. There is no inconsistency. Just a standard programming mistake. -- David Kastrup _______________________________________________ bug-lilypond mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-lilypond
