[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ‘Bleed-over’ with LilyPond assignment to a Scheme value
From: |
David Kastrup |
Subject: |
Re: ‘Bleed-over’ with LilyPond assignment to a Scheme value |
Date: |
Mon, 18 Jan 2016 17:32:09 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
Simon Albrecht <address@hidden> 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