Han-Wen Nienhuys <hanw...@gmail.com> writes: > On Fri, Jul 22, 2011 at 3:32 AM, David Kastrup <d...@gnu.org> wrote: > >>>> Anyway, this is not particularly complex either. Could possibly pave >>>> the way for a nicer function for setting up strings for tabulatures. >>>> Also stuff like \transpose can be implemented by users with a >>>> straightforward syntax accepting just pitches where pitches are asked >>>> for, without the user needing to disassemble music in order to get at >>>> the pitch somewhere in the center of the mess. >>> >>> It would be awesome to implement \transpose (and relative, for that >>> matter) as a music function. >> >> Not likely a speed gain. > > > It's not for speed. I have always been annoyed by the special parser > rules for those, so it would be neat to be able to drop those. > > >>> It seems to be missing the init for the _proc variables you added, >>> though. >> >> No. They are created by the existing calls of IMPLEMENT_TYPE_P in >> pitch.cc and duration.cc and initialized there. > > Ah, I forgot. LGTM then.
I'll try fudging up documentation for it, and I'll check the perspectives for minimizing the combinations of duration and music arguments that are not either accepted or flagged with a proper error message rather than a generic syntax error. With regard to merging: this is an incompatible change since arguments of type ly:pitch? or ly:duration? previously asked for Scheme arguments like #(ly:make-pitch ... or #(ly:make-duration The Lilypond codebase does not contain such music function arguments I think. It should actually work to convert them to #(ly:export (ly:make-pitch ... so there is a straightforward (but more likely than not untowardly awkward) migration path. Apart from this change in semantics, this should not cause regressions. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
