Re: melismaBusyProperties: scheme syntax vs. lily syntax

[Thomas Morley]

2018-07-16 11:32 GMT+02:00 David Kastrup <address@hidden>:
> Thomas Morley <address@hidden> writes:

>> Though, I remember at least one instance where `make-engraver' failed
>> for a very special use-case.
>> Then I tried the scheme-list-syntax for engravers and found it worked.
>> Asking on the list, David K confirmed a certain limitation in
>> `make-engraver`.
>> Meanwhile we had eliminated the scheme-list-syntax for engravers from
>> our source completely, without having stored some examples of old
>> list-syntax-engravers I would have been lost.
>
> To be fair, the doc string of make-engraver is
>
>     "Helper macro for creating Scheme engravers.
>
>     The usual form for an engraver is an association list (or alist)
>     mapping symbols to either anonymous functions or to another such
>     alist.
>
>     @code{make-engraver} accepts forms where the first element is either
>     an argument list starting with the respective symbol, followed by the
>     function body (comparable to the way @code{define} is used for
>     defining functions), or a single symbol followed by subordinate forms
>     in the same manner.  You can also just make an alist pair
>     literally (the @samp{car} is quoted automatically) as long as the
>     unevaluated @samp{cdr} is not a pair.  This is useful if you already
>     have defined your engraver functions separately.
>
>     Symbols mapping to a function would be @code{initialize},
>     @code{start-translation-timestep}, @code{process-music},
>     @code{process-acknowledged}, @code{stop-translation-timestep}, and
>     @code{finalize}.  Symbols mapping to another alist specified in the
>     same manner are @code{listeners} with the subordinate symbols being
>     event classes, and @code{acknowledgers} and @code{end-acknowledgers}
>     with the subordinate symbols being interfaces."
>
> Which is sort of more than was there in forms of explicit documentation
> (rather than only example code) for engravers earlier.  If you compare
> with the actual macro _code_, you'll find that this doc string contains
> a whole lot more information about the details of Scheme engraver
> anatomy than the actual macro code (which is not interested in any of
> the described names but just maps one structure to another).

It _is_ a good doc-string, no doubt, albeit it's not part of any manual.

And I thought more about sort of a table like the comparison of
http://lilypond.org/doc/v2.14/input/regression/b8/lily-002a5ef5.ly
and
http://lilypond.org/doc/v2.19/input/regression/7d/lily-f57bd45c.ly

Of course one could argue, both are not _ly_-syntax, but speaking only
for me, I think it's very instructive having an example in both
syntax.

Cheers,
  Harm