lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LSR updates: was: polychords: a working solution


From: David Kastrup
Subject: Re: LSR updates: was: polychords: a working solution
Date: Fri, 24 Feb 2012 14:19:00 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

David Nalesnik <address@hidden> writes:

> David,
>
> On Fri, Feb 24, 2012 at 12:44 AM, David Kastrup <address@hidden> wrote:
>
>     David Nalesnik <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]