On Mon, Mar 16, 2026 at 1:54 PM Lukas-Fabian Moser <[email protected]> wrote:
> to me it sounds as if you're missing the point that lyrics are parsed in a
> fundamentally different way from other music.
>
I was not aware \lyricmode is a parser thing, I thought it'd be one of
those things David was just talking about the other day,
that really it's scheme after all (I seem to recall his examples included
\time and several others, it's in that "new parser" thread)
Besides, why does this thing have to be a music function? Could it not be a
normal scheme callable that calls a music function internally?
> 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.
>
I'll take a look, thanks for the tip
> So you would have to implement \parallelMusicExtended directly in the
> lexer/parser
>
Yeah that's clearly very heavy handed, unless a lot of users wanted this,
it doesn't seem worth the effort
> in such a way that it automatically switches to lyric state between the
> specific | ... | pair that the user specifies
>
I was thinking more something like (in python syntax):
contents = []
for i,span in enumerate(contents.split('|')):
contents[i%4] += span
variable[i] = interpretAs(mode[i], content[i])
where the input pairs go fill in the mode[i],variable[i] arrays, and "4" is
how many entries you have in your first argument.
In other words: take the input unprocessed, reconstitute the input as
"vanilla" lilypond would take it, process it normally.
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"?
>
I see what you're saying. But this is an argument line that when I hear it,
my heart dies a little. By that same argument, why ever change anything at
all,
it's more pragmatic to do things like we've always done them.
Me, I have spent a good portion of my time (paid or not) doing things in
ways different from how "we've always done them", sometimes with good
results
(you can go look around the web, if you're curious, there is evidence
around).
There is that famous quote (attributed to GB Shaw, iirc) that the
reasonable man adapts himself to his environment, and the unreasonable man
adapts his environment
to himself, thereby all progress depends on the existence of the
unreasonable man.
This is all to say "forgive me, but I don't like that argument".
I maintain: if you're making something simple like wanting lilypond to
print a leadsheet with words,
this would make the input much more readable. In my head, the thing you
want to come out of the program
should kinda have as similar as possible a structure to the thing you're
putting into the program,
because this lowers the cognitive load of the editor, and frees up brain
space to spend on the
content, instead of having to wrestle with the formal aspects of the
language you're using.
I don't know how many people write simple music like this with lilypond, is
it of interest to the lilypond
authors/maintainers that this number would grow, though? Would this change
help that growth?
Anyways, it's sounding like it's a fairly non-trivial thing to achieve,
unfortunately
Thanks for your help folks
L
--
Luca Fascione
