Re: Making a \layout definition in Scheme

[Urs Liska]

Am 04.04.2018 um 19:25 schrieb David Kastrup:
> Urs Liska <address@hidden> 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