Urs Liska <u...@openlilylib.org> writes: > Am 19.07.2017 um 10:43 schrieb David Kastrup: >> Urs Liska <u...@openlilylib.org> writes: >> >>> Obviously I didn't make myself clear enough and probably I should have >>> invested the time for a minimal example. When sloppily using the word >>> "override" I didn't mean "\override" but applying a value to a grob >>> property in a grob callback function. >>> >>> I have a data structure idTweaks, currently using an alist: >>> >>> idTweaks = #'() >>> >>> This alist gets populated with elements consisting of a key and a >>> #'(property . value) pair with >>> >>> idTweak = >>> #(define-void-function (id prop val)(string? symbol? scheme?) >>> (set! idTweaks (assoc-set! idTweaks id (cons prop val)))) >>> >>> using commands like >>> >>> \idTweak "id-1" color #red >>> \idTweak "id-2" extra-offset #'(2 . -2) >> You are aware that >> >> idTweaks.id-1.color = #red >> idTweaks.id-2.extra-offset = #'(2 . -2) >> >> would have done the same? > > No! > (but only if id-1 were a symbol, right?
Ouch. I grow old. In Scheme, it is, but of course not in LilyPond. idTweaks.1.color would actually work (but be something different) and idTweaks."id-1".color = #red would work in current versions (and be the same as your code). I had a longstanding idea where LilyPond would accept alists which could use either a hash or vector rather than a pair as element (or even tail?) of an alist. Obviously that could speed up some operations (and at least the default grob properties would not significantly slow down the lookup of either them or unset properties). One would also be able to "compress" such lists on-demand and convert them into hashtables. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
