Re: [frogs] Enhancement request: Define output-suffix as a configurable context property. |
[ Thread Index | Date Index | More lilynet.net/frogs Archives ]
Carl Sorensen wrote:
Wouldn't I need to add a dependency to the build, too?On 9/20/09 5:40 AM, "Ian Hulin" <ian@xxxxxxxxxxxx> wrote: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.OK, I guess I agree with what you said.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 ...} }Yes, this is more general than my suggestion.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.scmThis seems like a good idea to me. However, I'm not really strong on parser variables. But if this does work, I think it would be an improved way of handling point-and-click, because, as you say, it would tie into the existing LilyPond syntax.Remaining things to do would be * add define-parser-variable-properties.scm to build (whimper...)No (whimper...) needed here; this is trivial to do. Just add an entry to scm/lily.scm. Presumably the same way it decides whether to access a context property, music property, or grob property currently.* get the property access routines to use the new all-pv-properties listI'm not sure I have this vision. How would \set know whether to set a context property or a pv property? That's something I'll have to dig into. I was sort of assuming the \set code did a lookup of available property lists, I'll undertake further research. Cheers, Ian |
Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |