Hi Luca,
But then thislong string would be extremely unwieldy as input, so
I can’t imagine
that being worth it.
I don't follow, why isn't it identical to what parallelMusic takes today?
What am I missing here?
Forgive me if that's something you already know, but to me it sounds as
if you're missing the point that lyrics are parsed in a fundamentally
different way from other music. Explicit \lyricmode (or \lyrics or
\lyricsto or \addlyrics) puts the Lexer into state 'lyrics' which reads
its input in a, so to speak, different language than the main part of a
LilyPond file. There seems to be no way of telling LilyPond in the
definition of a music function that some parameter should automatically
get lexed/parsed in a different lexer state, see lily/lexer.ll.
So you would have to implement \parallelMusicExtended directly in the
lexer/parser in such a way that it automatically switches to lyric state
between the specific | ... | pair that the user specifies. This might be
possible, but it's quite definitely not something that can be obtained
by just writing another music function.
I prefer C, but my aim is an input form that has high locality of
reference:
things close to each other in the PDF I want to be close to
each other in the input (with is what parallelMusic achieves).
I see the appeal, but given the complexities involved with switching
lexer states etc., maybe it's more pragmatic to switch to a different
goal, i.e. "keeping the lyrics together"?
Lukas
