Re: Fixing issue 786 (lyric extenders) again

[Chris Snyder]

> Yes, I am top-posting

I notice that issue 786 was just marked as critical. I sent the 
following message to -devel four weeks ago but never received a 
response. I'd appreciate advice on how to write messages that are more 
responder-friendly.

Chris Snyder wrote:
> Issue 786, which was caused by a patch I submitted back in March, was 
> recently re-opened with another case of an extender being completized 
> too early. Looking at the example, it's easy to spot what's going on. 
> The fix, however, looks to me to be less straightforward.
>
> Some background:
> The original patch fixed an issue where an extender would go too long 
> (sometimes to the end of the score) when the lyrics ended before the 
> associated voice. This was because extenders were only completized when 
> the next event in the Lyrics context came along, which would never occur 
> if the Lyrics block ended with an extender. My original patch added a 
> check to see if the voice was in a melisma and to completize the 
> extender if not.
>
> One problem this caused (original issue 786) was with manual melismata, 
> which the melisma_busy(voice) function doesn't know about (and can't - 
> it doesn't know about Lyrics contexts at all, nor should/could it, since 
> multiple Lyrics contexts can be associated with one voice). This was 
> fixed by changing the Lyric_engraver to add empty LyricText objects. The 
> Extender_engraver checks both melisma_busy and for the presence of an 
> empty LyricText object, and only completizes the extender if neither is 
> true (as well as another check to fix issue 800).
>
> The case that caused issue 786 to be reopened, however, poses yet 
> another problem. It is more general than just happening with beamed 
> notes - I've verified the same behavior with slurs and ties as well. It 
> happens whenever an automatic melisma (beam, slur, tie) is followed by a 
> manual one (underscore in Lyrics). Looking at the checks I added, it's 
> obvious what's happening: On the last note of the automatic melisma, 
> melisma_busy returns false, but the empty LyricsText object won't occur 
> until the next moment, so the Extender_engraver thinks it should 
> completize the extender.
>
> Under the scheme as it exists now, the Extender_engraver would have to 
> somehow check for an empty LyricText object occurring in the future. 
> This doesn't seem to me to be the correct approach.
>
> Alternatively, I've thought of another solution that seems to be more 
> elegant than this growing list of checks for various cases: what if the 
> parser created an empty LyricText object at the end of each Lyrics 
> block? That would solve the original issue I fixed back in March in a 
> way that would allow us to revert that part of the Extender_engraver to 
> the way it was before my original patch. Before I try to learn how the 
> parser works, does this seem like an acceptable approach?
>
> Thanks,
> -Chris