Hi Carl,
That will work, but it's still a work-around. We'd be avoiding setting
it as a context property to keep the architectural thinking clean, while
at the same time duplicating the functionality of a property by hand.
What we're in effect doing here is duplicating the behaviour of a
property, we're hiding the parser variable and writing a function to
write to it. So why not
pvSet =
#(define-music-function (parser layout parser-variable new-value) (variable?
string?)
(set! parser-variable new-value)
(make-music 'SequentialMusic 'void #t))
then do
\book {
\pvset output-suffix "gibbon-vole-aardvark"
{... \score blocks and things ...}
}
But I'm still bothered we may be re-inventing the wheel here. We've got
properties in lily already, and defined ways of setting them (\set,
\override and even assigning them in the relevant block).
Could we not add a new define-parser-variable-properties.scm with
(define-public all-pv-properties '())
(define (pv-property-description symbol type? description)
(if (not (and
(symbol? symbol)
(procedure? type?)
(string? description)))
(throw 'init-format-error))
(if (not (equal? #f (object-property symbol 'translation-doc)))
(ly:error (_ "symbol ~S redefined" symbol)))
(set-object-property! symbol 'translation-type? type?)
(set-object-property! symbol 'translation-doc description)
(set! all-pv-properties (cons symbol all-translation-properties))
symbol)
(define-public all-pv-properties
(map
(lambda (x)
(apply pv-property-description x))
`(
(output-suffix ,string? "Text to append to the output
filename for the current @code{\\book} block")
;;; Maybe add all the other supported parser variables here?
)))
The above should work as I've adapted it unashamedly from
define-context-properties.scm
Remaining things to do would be
* add define-parser-variable-properties.scm to build /(whimper...)/
* get the property access routines to use the new all-pv-properties list
This would be more work, but give us a cleaner result and it would be
less likely to fall foul of a fatwah from new Syntax Standardization
project when it gets going.
Opinions?
Cheers,
Ian
Carl Sorensen wrote:
On 9/19/09 7:27 AM, "Ian Hulin" <i...@hulin.org.uk> wrote:
Hi Carl, Neil,
I'm quite happy to re-think the proposal if what I have in mind contravenes
existing design architecture.
Put it down to relative inexperience and the fact I don't get opportunity to
work on lilly as often as I'd like.
Anyhow, here are some of the reasons why I'd like to do something with this
stuff:
* Using parser variables to configure things is evil, because it requires
users to drop into Scheme to set the parser variable. I feel we need to
replace #(define output-suffix "gibbon-vole-aardvark") with something handled
at the lilypond language level.
*
* At the moment, output-suffix is de facto a property of a \book block.� There
is a design assumption (informal club rule) in lilypond� that we only produce
one back-end output file (.pdf, .png whatever) per \book block.
* However, there is as great big exception to this in the form of midi files,
one of which one is output for every \score block with a \midi present. At the
moment the file name generation code kludges its way around this but it not
very clean, unclear and all this stuff is barely documented.
* So what I'd like to do is to have some way of replacing the Scheme
definition either -
* \book {
* ��� \set output-suffix "gibbon-vole-aardvark"
* ��� {... \score blocks and things}
* }
* , or
* \book \with {output-suffix = "gibbon-vole-aardvark"}
* {
* �� {... \score blocks and things}
* }.
Could one define a void music function
setOutputSuffix =
#(define-music-function (parser layout new-output-suffix) (string?)
(define output-suffix new-output-suffix)
(make-music 'SequentialMusic 'void #t))
then do
\book {
\setOutputSuffix "gibbon-vole-aardvark"
{... \score blocks and things ...}
}
I haven't tried it, but I think it may work.
Carl
---
----
Join the Frogs!
______________________________________________
This email has been scanned by Netintelligence
http://www.netintelligence.com/email
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
