Hi Luca,
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)
Yes, I've followed that thread a bit. It's true that a very large
percentage of core LilyPond functionality is now defined in terms of
LilyPond definitions and Scheme code (i.e. "clef =
#(define-music-function ..." etc.). But in the parser, we still find:
%token ACCEPTS "\\accepts"
%token ADDLYRICS "\\addlyrics"
%token ALIAS "\\alias"
%token ALTERNATIVE "\\alternative"
%token BOOK "\\book"
%token BOOKPART "\\bookpart"
%token CHANGE "\\change"
%token CHORDMODE "\\chordmode"
%token CHORDS "\\chords"
%token CONSISTS "\\consists"
%token CONTEXT "\\context"
%token DEFAULT "\\default"
%token DEFAULTCHILD "\\defaultchild"
%token DENIES "\\denies"
%token DESCRIPTION "\\description"
%token DRUMMODE "\\drummode"
%token DRUMS "\\drums"
%token ETC "\\etc"
%token FIGUREMODE "\\figuremode"
%token FIGURES "\\figures"
%token HEADER "\\header"
%token INVALID "\\version-error"
%token LAYOUT "\\layout"
%token LYRICMODE "\\lyricmode"
%token LYRICS "\\lyrics"
%token LYRICSTO "\\lyricsto"
%token MARKUP "\\markup"
%token MARKUPLIST "\\markuplist"
%token MIDI "\\midi"
%token NAME "\\name"
%token NOTEMODE "\\notemode"
%token OVERRIDE "\\override"
%token PAPER "\\paper"
%token REMOVE "\\remove"
%token REPEAT "\\repeat"
%token REST "\\rest"
%token REVERT "\\revert"
%token SCORE "\\score"
%token SCORELINES "\\score-lines"
%token SEQUENTIAL "\\sequential"
%token SET "\\set"
%token SIMULTANEOUS "\\simultaneous"
%token TEMPO "\\tempo"
%token TYPE "\\type"
%token UNSET "\\unset"
%token WITH "\\with"
For most of them, it's not that surprising that they still are
implemented directly in the parser (for example, \etc, \with, \header,
\consists etc.) since they obviously perform low-level operations. But
for some it's not as obvious: \tempo might, for all intents and
purposes, be implemented as a usual function. I do not know whether it's
the only reason, but one reason for this is certainly the
\tempo Allegro 4 = 120
syntax, since it's simply not possible (as far as I can see) to make a
music function accept a "x = y" argument.
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?
I'm sorry, I don't understand - could you reword this?
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.
Yes, that would be nice. But the content of the { | ... | ... }
construct is parsed before a music function can take its elements. So,
as Simon said, we could only do some trickery to accept strings in
normal music input mode, for instance:
\parallelMusicExtended #'((chordmode . chords) voiceA (lyricmode .
lyricsOne) (lyricmode . lyricsTwo)) "{
c2.-"maj7" |
c2 e8 c |
-"ma -- zing __ _" |
-"grace that __ _" |
}"
Then a music function could split these strings up and feed them into
the parser.
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".
Yes, sure. Probably my argument very much depended on me being quite
happy with having my lyrics in one large block.
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?
I honestly do not know. After 20 years of using LilyPond, the idea of
having multiple simultaneous long-range horizontal elements that make up
a score (the first violin, the tenor, the lyrics, the chords ...) feels
so natural that I can't really say whether for new users, a more "local"
approach would feel easier to work with.
Lukas
