Re: New read/eval Scheme syntax inconsistent in handling existing code

[Valentin Villenave]

On Mon, Nov 21, 2011 at 7:39 PM, David Kastrup <address@hidden> wrote:
> With all due respect,

Really? Who are you and what have you done with David? :-)

> I doubt that.  The reason is rather boring: my
> changes broke ly:parser-include-string because I did not understand what
> the pending_include whatever were for.  I pushed two changes to staging
> just now fixing this.

Glad to hear it.

> While the above example works fine now, when
> using ly:parser-include-string, it is preferable to use $ to avoid
> having your string getting injected _asynchronously_ after parser
> lookahead (the above use is in a place without lookahead).

Yes. I did figure that much.

> A bug that made it through the reviews, nothing inherently bad about the
> design.  Thanks for the test example, by the way.

Yes, it looks probably a bit far-fetched but said bug did break all of
my scores! (Hence the disruption thing.)

> The above file works fine with current staging.  Since you, as opposed
> to the Lilypond code base, appear to make extensive use of
> ly:parser-include-string, you might want to consider contributing a few
> regression tests capturing the essence of your usage patterns.

That's what I wanted to know: since parser-include-string was
originally implemented upon a request of mine, I wasn't sure it was
considered vanilla LilyPond syntax and supported as such.

Do you think this warrants a regtest of its own, or should it rather
be added to include-string.ly?

Cheers,
V.