David Nalesnik <david.nales...@gmail.com> writes:
> David,
>
> On Wed, Feb 13, 2019 at 8:35 AM David Kastrup <d...@gnu.org> wrote:
>>
>> David Nalesnik <david.nales...@gmail.com> writes:
>>
>> > On Wed, Feb 13, 2019 at 7:49 AM Trevor Bača <trevorb...@gmail.com> wrote:
>> >>
>> >> Could somebody else possibly provide James a patch of David N.'s
>> >> alternateTextSpannerEngraver?
>> >>
>> >> Trevor.
>> >
>> > The issue which would come up is that it is written in Scheme, rather
>> > than C++. This has implications for documentation.
>>
>> It does? What kind of documentation cannot be achieved in Scheme that
>> would be possible in C++?
>>
> Ah, OK, thanks for the update. I must be thinking of a past state of affairs.
commit df854ae456ad2e57139ddcb345760b4c321e1cbb
Author: David Kastrup <d...@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 <d...@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 <d...@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.
This is not even yesteryear's news but yonderyesteryear's news. Not
that 2 years are a lot of time at the current development speed.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
