Reinhold Kainhofer <reinh...@kainhofer.com> writes:
> On 28/07/2012 07:32, David Kastrup wrote:
>> Reinhold Kainhofer <reinh...@kainhofer.com> writes:
>>
>>> The text spanner implemented in scheme (which is also used as a basis
>>> for David's measure counter engraver) seems to work fine in the regtest,
>>> but apparently it is not quote-proof.
>>>
>>> In particular, if you try call \addQuote on some music that contains
>>> \schemeTextSpannerStart or \schemeTextSpannerEnd, then you get the
>>> following warnings and the text spanner is not quoted:
>> Well, scheme-text-spanner changes the \Global context, and quote
>> environments uses the layout definition partCombineListener in
>> ly/declarations-init.ly with an unchanged Global context.
>>
>> Change its Global context similarly, and you should be set.
>
> How can a user, who wants to use e.g. the measure counter engraver,
> change the partCombineListener' s Global context without messing with
> the original lilypond sources?
Uh, in the same manner as he changes the normal Global context?
> Am I missing something?
I don't understand the problem. You do something like
partCombineListener = \layout {
\partCombineListener
\context {
\Global
\grobdefinitions ...
EventClasses = ...
}
}
> The whole point of scheme engravers and scheme text spanners is that
> users can now also implement things in scheme without messing with the
> lilypond sources...
> If I understand you right, then the user cannot add new grobs in an
> include file without messing with the lilypond sources.
Make no mistake: scheme-text-spanner is a heap of junk messing with
LilyPond internals. Less so than previously, but still far too much.
So yes: for all practical purposes, the user cannot add new grobs. What
scheme-text-spanner does is not a user interface. It is code
duplication and hacking with internals. You can extend this hackery to
the partCombineListener if you want to. But scheme-text-spanner does
not in _any_ way constitute a user-accessible mechanism that is
guaranteed not to break either now or in future.
> Would a proper solution be to change the partCombineListener to a
> context mod and construct the real listener when we need it (i.e.
> replace the current (ly:parser-lookup parser 'partCombineListener) by
> the actual creation of the listener from the context in effect when
> add-quotable or recording-group-emulate is called?
I have no clue what you are talking about. partCombineListener is an
output definition, and I see no problem with it that would be any
different from that of the normal \layout output definition.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
