Re: [frogs] [PATCH]: Tracker 836 - Allow output filename and output-suffix to be specified for a \book block

[Ian Hulin <ian@xxxxxxxxxxxx>]

Carl Sorensen wrote:
> On 10/23/09 5:52 PM, "Ian Hulin" <ian@xxxxxxxxxxxx> wrote:
>
> > init.ly - Add new parser variables book-output-suffix and book-filename
> > initialized as #f and empty queue/stack structure.
> >
> > music-functions-init.ly adds three new functions
> > * \bookOutputSuffix - to set the output suffix for the \book block
> > * \bookOutputName - to set output filename for the current \book block
> > * \bookOuptutNameRevert - to restore the the output filename to the value
> > prior to that of the last \bookOuputName call.
>
> I think these functions should be named
>
> \setBookOutputSuffix
> \setBookOutputName
> \revertBookOutputName

You're probably right.  It's just that in music-functions-init the 
source likes to group all the functions alphabetically, and this was a 
way of getting all the related things together.

It's a shame we haven't got a way of declaring generic functions with 
the parser so you could code  \bookCommand \OutputSuffix "mysuffix". 
Well, I suppose we have if you imitate what \markup does in the parser 
but I'm not going to go there...

So I'll go with your suggestions.

> > \bookOutputName and \bookOuptutNameRevert use the book-filename as a stack
> > structure.  I have used this so we can we could eventually allow users to do
> > stuff like the following (controlling the names used to open the midi files is
> > not part of the current patch).
> > \book {
> >     \bookOutputName "My-Homeland"
> >     \score {
> >        \bookOutputName "Vysehrad"
> >           music-declarations ...
> >           \midi{
> >           % midi file gets written to Vysehrad.mid(i)
> >           }
> >           \layout{
> >           }
> >        \bookOutputNameRevert
> >     }
> >     \score {
> >         \bookOuputName "Vltava"
> >         ...
> >         \midi {
> >         % midi file is written to Vltava.mid(i)
> >         }
> >     }
> > .
> > .
> > .  
>
> This code doesn't demonstrate the need for \bookOutputNameRevert; the same
> thing would happen if the \bookOutputNameRevert were omitted, as far as I
> can tell.

Consider this in one file Smetana.ly:

;;  Music for Má Vlast
\book {
	\bookOutputName "My-Homeland"
	\score {
		\bookOutputName "Vyšehrad"
		...
	}
	\score {
		\bookOutputName "Vltava"
		...
	}
	%%   three more \score blocks setting the output name
	\score {
		\bookOutputName "Blanik"
		...
	}
}

;; Music for "Bartered Bride Overure"
\book {
	% No \bookOutputName here
	% Until scoping for \book blocks is sorted out,
	% this block will get output to Blanik.pdf and Blanik.midi.
	\score {
	...
	}
}	



> > lily-library.scm has changes to the filename generating code in
> > print-book-with to pick up the current values of the new parser variables if
> > set before using the current output-suffix or result of a call to
> > ly:parser-output-name.
> > The routine to get the name now uses as combination of the current output name
> > and output suffix value to at as a key for the internal a-list of filenames
> > being written to during a compilation.
> >
> > lily-guile.hh, lily-guile.cc and parser.yy have code that I would like to use
> > to re-initialize book-output-suffix and book-filename to initial values on
> > encountering the end of a \book block, but  I've hit a dead-end currently in
> > this  as the code I tried to use in parser.yy negates the effect of calling
> > the new functions altogether.  If anyone with more experience of how bison
> > works has any better ideas as to how do this I'd be interested in hearing
> > them.
>
> It would seem to me (this is a relatively poorly informed opinion) that
> setting them to the initial values at the *start* of a book block would be a
> more sane way to do it that to reset them at the end of a book block.  Or is
> there something I'm missing?

D'oh, I was getting blown away by having to learn Bison and work out 
what was doing what, with which, to what, when, and by whom. . .

I'll try it out.

> HTH,
Thank, you, yes it does,

Cheers,
Ian

---

----
Join the Frogs!