I haven't had my previous email replying to this one come back yet from
the ML, but meanwhile I noticed that \clef was in the keyword table when
the denemo parser was written (in lily/lily-lexer.cc) but now it is
gone. so I looked at the history and found it went about 5 years ago.
This commit records when \clef ceased to be a keyword and became a music
function.
2005-12-16
Han-Wen Nienhuys * ly/music-functions-init.ly: add \bar and
\clef music
function
looking at the patch to music-functions-init.ly I see
+clef =
+#(def-music-function (parser location type)
+ (string?)
So it is expecting a string, which in the LilyPond code would be fixed
by scan_escaped_word pushing the STRING_ token onto the stack etc.
So our solution is correct while we are avoiding going down the music
function route.
Richard
On Wed, 2010-08-18 at 22:31 +0200, Nils Gey wrote:
> How is \clef "G" done in lilypond parser again? no sign of clef there, nor in
> the lexer. Denemo had \clef = CLEF in its list of tokens/escaped words so our
> scheme parser detects clef. I have a working rule in command_even with
>
> CLEF DBLQUOTE NOTENAME_PITCH DBLQUOTE
>
> but this is very custom because " -> DBLQUOTE is not an original parser.yy
> token. This alone is not bad because parser.yy can do \" in the parser
> itself, where lalr-scm needs tokens and does not accept strings or chars
> directly.
> Like I said, the \clef rule is working but it breaks other things this way
> because the lexer suddenly returns DBLQUOTE where the (lilypond-)parser does
> not expect them, e.g. here
>
> \context Voice = "PartPOneVoiceOne" \PartPOneVoiceOne
>
> so how is \clef done in lilypond? Maybe you told me already, but I forgot
> then :(
>
> Nils
_______________________________________________
Denemo-devel mailing list
Denemo-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/denemo-devel
