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

[ Thread Index | Date Index | More lilynet.net/frogs Archives ]


Carl Sorensen wrote:

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.

 
  
Wouldn't I need to add a dependency to the build, too? 
* 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?

  
Presumably the same way it decides whether to access a context property, music property, or grob property currently. 
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/