Paul Morris <p...@paulwmorris.com> writes: > Hi Amy, > >> I'm sorry I'm such a dunce, but with the amount of documentation >> supplied, make-engraver is extremely hard to grasp. > > I’d say you’re doing pretty well.
Quite better than par for the course I'd say. But then it takes some tenacity to be playing golf in a mine field. > As I understand it David Kastrup is working towards better integration > of scheme engravers into LilyPond, granting them “full citizenship”. > Once that is finished maybe we can work to improve the documentation. That's not actually related. I'm working (still issue 1375) on being able to _register_ Scheme engravers properly so that you can call on them using \consists "Name_of_engraver" and have predefined Scheme engravers be documented like their C++ counterparts in the LilyPond Internals manual. But while it makes it more feasible to change some engraver implementations to a Scheme implementation, it does not actually help one bit with writing a Scheme engraver from scratch (apart from lowering the barriers for LilyPond developers to convert some C++ engravers into Scheme, thus making it more likely that you'll eventually be able to find more example code to dig up inside of LilyPond). Apart from the registration/reflection bit, the only thing that might warrant improvement is how to allocate/create/manage per-instance storage for Scheme engravers. The current solution of using closures for that is awkward. But most of the awkwardness is in setting it up: the actual code working with per-instance data would not look significantly different with a more native scheme. So basically issue 1375 is in no way related to improving the documentation about Scheme engravers. It's just about letting them blend in a bit better with C++ engravers. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
