Re: scheme spanner in input/regression/scheme-text-spanner.ly not quote-proof

[David Kastrup]

Reinhold Kainhofer <address@hidden> writes:

> On 28/07/2012 07:32, David Kastrup wrote:
>> Reinhold Kainhofer <address@hidden> 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