Neil Puttock <[email protected]> writes:
> Hi Janek,
>
>
> On 1 August 2014 13:32, Janek Warchoł <[email protected]> wrote:
>
> I'm putting a modest bounty on
>> https://code.google.com/p/lilypond/issues/detail?id=4044 - this
>> problem is a nuisance for my work on predefined instruments, so i'd
>> like to see it disappear.
>
>
> I remember looking at this a while ago. If I recall correctly it's too
> early for context information to be available to the syntax constructor -
> if you look in ly-syntax-constructors.scm there's a helper function which
> is supposed to find the first existing voice context so the constructor for
> \addlyrics doesn't have to create one from scratch. There's a comment
> there noting it doesn't work (it says `rarely works' but I'm pretty sure it
> never does).
Well, yes, never. It consults a property 'type' which is not actually
part of a normal music expression (the way it is used, 'name was likely
intended). If you artificially inseminate it with something like
\displayMusic {
$#{ \withMusicProperty type #'ContextSpeccedMusic \new Voice = wow { c'1 } #}
\addlyrics { zing }
}
(the $#{ ...#} construct is needed to avoid \addlyrics doing its work
before \withMusicProperty is being called) then LilyPond crashes because
it then tries executing (music), namely calling a music expression as if
it were a function. This code path never was operative.
Ugh. So step 1 would be to make this work as intended and see how much
breakage this will cause. Step 2 is then seeing how troublesome it
might be to let it work for _any_ context. If people write things like
\new Staff { ... } \addlyrics { ... }
then it might be a bad idea to attach to the Staff. Or maybe it's not
more insane than what happens now. No idea.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
