Valentin Villenave <[email protected]> writes: > On Fri, Nov 25, 2011 at 6:18 PM, David Kastrup <[email protected]> wrote: >> Valentin, any more news of bad effects on your scores? Apart from the >> bug that should now be fixed? > > OK, I've now had a chance to test the staging code, it's certainly an > improvement! > > ... Aand I'm blocked by another bug (or unwanted behavior) that > affects nested levels of string evaluations. > > I have yet to track down the exact problem, but here's an example of > the quirks I used to rely upon: > > > myvar = { b'4 } > > $(eval-string "(define-public myvar #{ a'2 #} )" ) > > \new Staff \myvar > > > (Granted, this wouldn't have worked with previous versions either.
It wouldn't have worked but you used to rely on it? > But the mechanism is the same.) Huh? That is just the old well-known premature evaluation order timing problem that $ has inherited from #. Write #(eval-string ... instead and the example presumably does what you want. It looks like you complain that something that did not work before now can be kept from working when you rewrite it in a special discouraged and completely unnecessary way that is documented to work just as badly as # did before my changes. If that's the worst effect on your scores you can come up with, I can live with that. Apparently I lack the imagination to understand the nature of your problem given this example. Can you find an example that is better suited to my limited capacities? Or do you actually _rely_ on the wrong evaluation order for some strange reason? If you do, you'll be able to use $ (possibly in connection with *unspecified* to avoid interpretation) to get things evaluated in the old unnatural order. -- David Kastrup _______________________________________________ bug-lilypond mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-lilypond
