[Top][All Lists]

[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

reply via email to

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