David Kastrup <[email protected]> writes: > Thomas Morley <[email protected]> writes: > >> But for >> >> #(define-markup-command (foo parser location)() >> (display-scheme-music #{ \chordmode { c:m } #}) >> (interpret-markup parser location "xy")) >> >> \markup \foo >> >> I get this: >> >> Preprocessing graphical >> objects.../home/harm/lilypond-git/build/out/share/lilypond/current/scm/parser-ly-from-scheme.scm:70:21: >> In procedure ly:parser-clone in expression (ly:parser-clone parser >> closures ...): >> /home/harm/lilypond-git/build/out/share/lilypond/current/scm/parser-ly-from-scheme.scm:70:21: >> Wrong type argument in position 1 (expecting Lily_parser): #< >> Output_def> >> >> I've not a real clue what's wrong and how to fix/proceed. >> >> Any hint? > > #{ #} expects a usable "parser" and "location" variable to be in scope. > > However, inside of a definition > >> #(define-markup-command (foo parser location)() > > "parser" would be a layout definition, and "location" would be a > property list of alists. I strongly suggest not tampering with the > usual "layout props" variable names here. Even though _those_ are not > magic, the names "parser" and "location" are when encountering > #{...#}.
After issue 4422 <URL:https://code.google.com/p/lilypond/issues/detail?id=4422> passes, it's worth noting that #{...#} no longer relies on magic names. So your code will just work fine. Which does not make it a good idea, but at least it's one fewer weird error one can trigger. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
