Carl D. Sorensen <c_sorensen <at> byu.edu> writes: > As a temporary work-around, would it be OK for me to move all of the > fret-diagram specific properies into a fret-diagram-details property, > and document them all under fret-diagram-details in > define-grob-properties.scm?
OK, so I _finally_ got around to trying this change, and I ran into a major roadblock. As you may recall, the plan was to make a property fret-diagram-details whose value would be an alist, and then I could retreive the details and handle them using the same routines we use on props. The problem ... Alist values in Scheme must be atoms, they can't be lists. An alist is defined as '((Key1 . Value1) (Key2 . Value2) (Key3 . Value3)) So I can't define a property fret-diagram-details whose value is an alist. Actually, I can define that property, but I can't get the property value out, because it doesn't recognize the "pair" '(fret-diagram-details . ((prop1 . val1) (prop2 . val2))) as a pair. Instead, Scheme recognizes it as a list '(fret-diagram-details (prop1 . val1) (prop2 . val2)) which is _not_ an alist. I've tried everything I can think of, without success, to use a list as the "value" part of an alist-pair. I think it won't work. Any suggestions on (a) how to make this work, or (b) another method of defining subproperties that will allow us to move the fret-diagram specific properties out of the general namespace? I think that a wholesale redefinition of props to a hash table, rather than an alist, would work, but that would be a _major_ job. I'd certainly welcome any help that any of you can give me. I'm stumped. Carl _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
