[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ian Hulin
Subject: Re: [frogs] Enhancement request: Define output-suffix as a configurable context property.
Date: Sun, 20 Sep 2009 16:04:55 +0100
User-agent: Thunderbird (X11/20090817)

Carl Sorensen wrote:

On 9/20/09 5:40 AM, "Ian Hulin" <address@hidden> 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

pvSet =
#(define-music-function (parser layout parser-variable new-value) (variable?
    (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))
(define-public all-pv-properties
 (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

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]