Re: Weird issue with dotted-list-notation

[Urs Liska]

Am 23.03.2015 um 17:30 schrieb David Kastrup:
> Urs Liska <address@hidden> writes:
>
> > Am 23.03.2015 um 17:18 schrieb David Kastrup:
> > > Urs Liska <address@hidden> writes:
> > >
> > > > Hi David,
> > > >
> > > > thank you for taking the time looking into this.
> > > >
> > > > Am 23.03.2015 um 10:19 schrieb David Kastrup:
> > > > > Urs Liska <address@hidden> writes:
> > > > >
> > > > > > Well, I do have a minimal example outlining what I want to do, but
> > > > > > "unfortunately" this works exactly as expected:
> > > > > >
> > > > > > \version  "2.19.16"
> > > What's the exact version you are using?  One of the released ones?  If
> > > not, can you point to the respective commit id of LilyPond you are
> > > using?  The debug output refers to line numbers in parser.yy and rule
> > > numbers in the corresponding parser tables.  So it's sort of important
> > > to know the exact version of parser.yy one wants to look at.
> > It's a custom 2.19.18 build from
> >
> > d19e0da3
> > Release: bump VERSION.
> Ok thanks.  If you want to have more of a go at reproducing the problem,
> it's clearly also related to the use of \include, possibly in connection
> with some
> #(ly:parser-[whatever] "\\include ...")
> call.  It may be that the combination of
>
> \callacceptingsymbollist ... xxx.yyy.zzz
> \somevariantofinclude ...
>
> is at fault when the lookahead scope of the symbol list meshes with the
> \include.

OK.
The weird thing is that I can put any debug (display) or ly:message I 
want all the way from the signature down to the \include, and everything 
seems completely right, the output (i.e the state of all the variables 
in between) is always the expected.

So as of now I can only say people should use proper Scheme lists as 
argument or ensure there's a Scheme expression after the function call 
(and not a LilyPond one).
Do you think there's a chance to find the issue in my code or in the 
parser or do I have to live with that?

Urs