#1375 Enhancement: Scheme engravers support in engraver-init.ly and documentation

[Anonymous]

Originally created by: *anonymous

Originally created by: v.villenave
Originally owned by: dak@gnu.org

Since the 2.13.11, we've had the ability of implementing engravers using Scheme only.  However, this currently has two limitations: such engravers may not be directly \consisted in engraver-init.ly, and no proper documentation support has been implemented.

Read for example the following discussion, where an engraver had to be rewritten in C++ just because of these limitations:
http://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00541.html

[Google Importer]

Originally posted by: v.villenave

Adapt documentation backend to Scheme engravers

Scheme engravers don’t prevent doc build anymore

For now, Scheme engravers are just ignored but ideally
they should be included as well (perhaps in a separate
texinfo node?).

http://codereview.appspot.com/222630043

Labels: Patch-new
Owner: v.villenave
Status: Started

[Google Importer]

Originally posted by: pkx1...@gmail.com

Patchy the autobot says: passes tests.  Includes a full make doc

Labels: -Patch-new Patch-review

[Google Importer]

Originally posted by: v.villenave

David has a better solution in the works.

Labels: -Patch-review
Owner: dak@gnu.org

[David Kastrup]

Sorry, still on it.

[David Kastrup]

Issue 1375: Scheme engravers support in engraver-init.ly and documentation

This is sort of basic. For one thing, registered engravers will bleed
into the following sessions for now. For another,
ly:register-translator is very rigid about the format of the
translator description. Then there still is only support for Scheme
engravers (rather than other translators).

Documentation for the feature itself is basically non-existent, so are
regtests. As long as the feature is in a state where more than
internal use is not advisable, that's tolerable.

Consists of commits:

Register scheme engravers

This registers Measure_counter_engraver and Span_stem_engraver
to make them documented and callable like C++ engravers.

Create Translator_creator class

Previously, translators were created by copying from a context-less
instantiation of the translator containing its documentation. This had
several unpleasant consequences, the most problematic likely being the
inability to register Scheme engravers because their documentation would
be identical to all other Scheme engravers.

A new Translator_creator class takes over the task of creating
Translator instances when called with a context argument.

As a result of joining the mechanisms for Scheme engravers and C++
engravers, ly:translator-name and ly:translator-description are
reimplemented in a manner resembling object properties.

Let Translator constructor take a Context argument

This is the first step towards constructing rather than cloning translators
when creating contexts. On its own, it does not make sense, but the change
is large and mostly mechanical, so keeping it separate from the actually
difficult parts makes sense.

http://codereview.appspot.com/316190043

[Anonymous]

Passes make, make check and a full make doc.

[Anonymous]

Patch on countdown for February 2nd.

[Anonymous]

Patch counted down - please push.

[David Kastrup]

Pushed to staging as
commit df854ae456ad2e57139ddcb345760b4c321e1cbb
Author: David Kastrup dak@gnu.org
Date: Sat Jan 28 01:16:54 2017 +0100

Issue 1375/3: Register scheme engravers

This registers Measure_counter_engraver and Span_stem_engraver
to make them documented and callable like C++ engravers.

commit 6887546c5caf87cdc94252c020f39b43a57bf057
Author: David Kastrup dak@gnu.org
Date: Tue Jun 16 14:14:27 2015 +0200

Issue 1375/2: Create Translator_creator class

Previously, translators were created by copying from a context-less
instantiation of the translator containing its documentation.  This had
several unpleasant consequences, the most problematic likely being the
inability to register Scheme engravers because their documentation would
be identical to all other Scheme engravers.

A new Translator_creator class takes over the task of creating
Translator instances when called with a context argument.

As a result of joining the mechanisms for Scheme engravers and C++
engravers, ly:translator-name and ly:translator-description are
reimplemented in a manner resembling object properties.

commit 6d1c5d25389afa6dbbfb4722df3732e764cbbf2e
Author: David Kastrup dak@gnu.org
Date: Fri Jan 27 13:27:03 2017 +0100

Issue 1375/1: Let Translator constructor take a Context argument

This is the first step towards constructing rather than cloning translators
when creating contexts.  On its own, it does not make sense, but the change
is large and mostly mechanical, so keeping it separate from the actually
difficult parts makes sense.