Re: [frogs] Enhancement request: Define output-suffix as a configurable context property.

[Carl Sorensen <c_sorensen@xxxxxxx>]

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.scm

This 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.

 
> * get the property access routines to use the new all-pv-properties list

I'm not sure I have this vision.  How would \set know whether to set a
context property or a pv property?

Carl



---

----
Join the Frogs!