David Nalesnik <david.nales...@gmail.com> writes: > David, > > On Fri, Feb 24, 2012 at 12:44 AM, David Kastrup <d...@gnu.org> wrote: > > David Nalesnik <david.nales...@gmail.com> writes: > > > I wasn't able to apply this to the snippet, > > > Sigh. > > \lyricsto "chorus" \new Lyrics \txtChorus > \lyricsto "verse" \new Lyrics \txtVerseI > \ifTargetIn ... > > > > Sorry for being unclear: I did do what you suggested and it didn't fix > the problem. Doing the replacements yields this string of errors: > > GNU LilyPond 2.14.2 > Processing `filtering-parts-from-the-command-line.ly' > Parsing... > filtering-parts-from-the-command-line.ly:168:16: error: syntax error, > unexpected SCM_TOKEN, expecting EXPECT_MARKUP or EXPECT_MUSIC or > EXPECT_SCM or EXPECT_NO_MORE_ARGS > \ifTargetIn > #'(song) <<
The problem is caused because \new Lyrics switches modes by pushing on a lexer state stack and popping it when getting out again. Music functions in the lexer are converted into a MUSIC_FUNCTION token and a sequence of argument tokens pushed into a separate place, and then the lexer enters into "extratoken" state. The problem is that \new Lyrics pops its stack when the parser is sure that the lyrics have ended, and this is when it has seen the MUSIC_FUNCTION token. When it pops the lexer stack, consequently it pops the "extratoken" state instead of the "lyrics" state, and chaos ensues. I would have thought that enclosing the lyrics in braces was enough for the parser not to consider a lookahead token before deciding to pop the lyrics stack, but I probably overlooked something. Probably multiple \lyricsto are combined in some manner, so the lookahead token is needed to see whether there is another \lyricsto coming up. Ok, then my analysis was not good enough. One could enclose the whole \lyricsto construct in braces (from the outside), but then we are getting into the really ugly domain instead of the "innocent modifications" realm. Personally, I would aim for getting everything moved to 2.16. It seems somewhat pointless to do all the effort just to be lagging still a year behind, but of course that depends on the views of the LSR maintainer. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
