Carl Sorensen wrote:
On 9/20/09 5:40 AM, "Ian Hulin" <i...@hulin.org.uk> 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
