David Kastrup <d...@gnu.org> writes:
> Robin Bannister <r...@dataway.ch> writes:
>
>> On 14.02.2014 18:46, Pierre Perol-Schneider wrote:
>>> I cannot find where the problem comes from.
>>
>> Me neither; convert-ly doesn't rearrange anything.
>>
>>
>> If you move the "cue" voice down past the other
>> (anonymous) voice, then \lyricsto can find it.
>>
>> But surely you shouldn't have to do that?
>
> Sounds like a regression somewhere in the iterators related to cues. I
> am doing a bisection now. It's quite likely that some patch of mine is
> responsible here: I don't think many others messed with iterators in
> this iteration.
Huh.
105bc22bbb1887c9be2c5f6288a4f9249159f250 is the first bad commit
commit 105bc22bbb1887c9be2c5f6288a4f9249159f250
Author: David Kastrup <d...@gnu.org>
Date: Wed Aug 21 04:09:29 2013 +0200
Issue 3489: Let \cue... use quoted-context-type of CueVoice consistently
Previously Voice was used and this relied on a a CueVoice purportedly
being created by cue-substitute itself and providing a Voice alias.
There is a regtest input/regression/quote-tuplet-end.ly which relied
on an explicit Voice = "cue" serving as a substite catch for the cue
notes, effectively turning \cueDuring into \quoteDuring. This kind of
usage is rather bizarre, and since it diverts the \voiceOne/\voiceTwo
settings for the cue voice into a CueVoice context anyway (which is
otherwise empty), the cue voice is still missing proper directional
information. This was not worth supporting.
Regularizing the usage in this manner will reliably stop \quoteDuring
from introducing surprise CueVoice contexts.
:040000 040000 f957589346e20988d3832a991956e7e1944c0cbf
64c0507b9ddb48b961ce481b6e6c0e4530a7984e M ly
:040000 040000 f51486424a5a0afe6b734d279b33546c165309db
bc83b413a72b283c154de1318204e3910d488ff5 M scm
The LSR snippet looks suspiciously like the code described in the commit
message as "bizarre". In fact, staring at the snippet gives me a
headache. I have a real problem figuring out what it is trying to do in
the first place. I'll probably have to look at the output and determine
what is supposed to happen backwards from there, and I would not be
surprised if it worked mainly by accident. The code looks like it has
been poked with a stick until it happened to produce the current output.
--
David Kastrup
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
