Re: Issue 754: don't transpose generic property-setting music commands (issue 7303057)

[k-ohara5a5a]

On 2013/02/11 12:39:02, dak wrote:
> On 2013/02/11 09:25:20, dak wrote:
> > On 2013/02/11 06:18:57, Keith wrote:
> > >
> > > I was hoping to be able to provide a backward-compatibility
function, as in

> > I did not even look at the proposed patch but it touches several
binaries.
> That
> > should not be necessary.  Of course, in this variant of the patch,
it would be
> > feasible just to put untransposable back to #f, but since the
followup work
> > includes reversing the sign of the pitch again, this is a dead end.
I think
> > that something using ApplyContext should be workable, though, so
that the
> > compatibility function gets along just using LilyPond/Scheme and can
be loaded
> > on-demand.

Well, my previous suggestion for backward-compatibility used LilyPond,
but you promptly adjusted your patch to stop my suggestion from working.

> oldTransposition =
> #(define-music-function (parser location pitch) (ly:pitch?)
>    (make-music 'SequentialMusic
>     'pitch (ly:pitch-negate pitch)
>     'elements-callback
>     (lambda (m)
>      (list
>       #{ \transposition $(ly:pitch-negate
>                          (ly:music-property m 'pitch))
>       #}))))

Great.  The pitches in structures built by make-music (differently to
those created by property-set) are molested by \transpose, but then a
sneaky callback tampers with the music and creates -- wait for it -- a
nested property-set!  It just goes to show that people will take
advantage of _any_ reproducible behavior, no matter how inconsistent.

Just kidding.  This should be fine for a backward-compatibility
function, in case anyone has a 200-page score that accidentally depended
on the old behavior.

https://codereview.appspot.com/7303057/