Re: Nashville notation as chord symbols

[David Kastrup]

Paul Morris <address@hidden> 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