Am 04.04.2018 um 19:25 schrieb David Kastrup:
Urs Liska <li...@openlilylib.org> writes:
OK, but now I have a follow-up question which is quite similar to my
other post from today (and I'm afraid the answer is similarly
embarrassing):
I managed to install an editionID to a specific movement's score with
this code:
(ly:score-add-output-def! score
#{
\layout {
\context {
\Score
#(editionID #f movement-path)
}
}
#})
which actually works when I use that "movement-path" variable to
address in \editionMod later.
However, I would like to be able to also write this without the
permanent switches,
Permanent switches? Huh?
Well, 'permanent' is of course the wrong word. What I'm (somewhat)
taking issue with is switching languages back and forth within one
expression.
i.e. in pure Scheme syntax.
Why? Seriously.
My project library is getting more and more pure Scheme code, and while
sometimes I wonder if it's worth the effort it usually turns out to do
so, for example because things immediately become easier to maintain or
extend afterwards.
So that's why I'm looking for ways to "smoothen" code snippets like the
one listed above.
But unlike \key I can't simply "call" layout.
My impression (after looking at the Scheme functions reference page
and a number of source files) is that I could use (ly:make-output-def)
to create the output definition and then use
ly:output-def-set-variable! to achieve the goal.
An output definition created from scratch will be neither layout
definition, midi definition, nor paper block. You are better off
copying an existing template. Which is what #{ \layout ... #} does
($defaultlayout or something like that).
But after trying out a number of things I must admit I don't get to an
end with it.
So again I have to hope for any hint ...
If you want to replace the parser with your own Scheme code, your best
bet is to look in lily/parser.yy and check what the actual parser code
does. There is no user-level documentation for rewriting any LilyPond
code in Scheme. Because it would be sort-of pointless given the
user-level #{ ... #} construct.
The file I'm working on is only halfway "user-level", since it's the
machinery hidden from the user in a black box.
However, considering your comments above I assume that in *this* case
it's the better choice to simply leave it as it is.
Urs
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
