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/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
