Comment #4 on issue 2024 by d...@gnu.org: Patch: Let #{ ... #} pass its $ handling to environment cloning
http://code.google.com/p/lilypond/issues/detail?id=2024
I am rather serious about this. The last upload removes all uses of ly:export _via_ convertrules. Automatically, even though this involves non-trivial editing of Scheme code and embedded Lilypond. In the process, it slightly changes the call syntax of, I think, 5 Scheme functions which, for no imaginable reason whatsoever, are called in Scheme rather than as music functions, but return a packed identifier that is only ever useful used in Lilypond syntax.
This is not a question of GLISS but rather of sanity. This patch does not address the sanity angle; it merely requires the user to use $ when using those functions rather than #. As a side benefit, their return values are now useful when called from Scheme, but I doubt anybody actually wants to do that. They should really be turned into music functions. All manual uses of ly:export are also patched away, and definition and use of a similarly weird function in the baerenreiter regtest are automagically detected and changed.
After this gets accepted, I will remove ly:export altogether, and split the phases of reading and evaluation # expressions, getting rid of their synchronization problems.
You better review this before it passes a countdown. As I said, I am dead serious about it. It straightens out a lot of wrinkles and inconsistencies in the interaction of Lilypond, Scheme, and #{ ... #} code blocks, with an interplay that is logical and understandable rather than a series of unrelated hacks.
You'll need to handbump VERSION for reviewing at the moment, since convert-ly has to pick a not-yet existing release number. Let's hope that we get the official version bump soon.
_______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
