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

[dak]

On 2013/02/11 09:25:20, dak wrote:
> On 2013/02/11 06:18:57, Keith wrote:
> > On 2013/02/09 08:54:03, dak wrote:
> >
> > > It doesn't matter.  LilyPond is still being actively maintained.
If a
> > > feature is required, it can be implemented properly, with a proper
> > > interface, _without_ resorting to exploits.
> > >
> >
> > I was hoping to be able to provide a backward-compatibility
function, as in
> > <https://codereview.appspot.com/7312074/>, just in case someone used
> > \transposition inside of \transpose the way it used to work.

> 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.

Ok, ApplyContext does not cut it since it does not offer access to the
original music.  But try, for example,
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))
     #}))))

and you'll see that \oldTransposition will just make the old behavior
available again.  You can't assign this particular definition to
transposition, for obvious reasons, but saving and using the old value
of \transposition should be doable in an obvious manner.

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