David Kastrup <d...@gnu.org> writes:
> Kieren MacMillan <kieren_macmil...@sympatico.ca> writes:
>
>> Hi David,
>>
>>> Uh, a markuplist typically _is_ a list of markups. Except when it isn't
>>> (like when it is the result of calling a markup list command). But when
>>> it isn't, you can only turn it into a list of stencils.
>>
>> Hmmm… So in my function
>>
>> #(define-markup-list-command (diffints layout props mus) (ly:music?)
>> (interpret-markup-list layout props
>> (map (lambda (d) (if (zero? d) "0" (format #f "~@d" d)))
>> (let ((muspst (map ly:pitch-semitones (music-pitches mus))))
>> (map - (cdr muspst) muspst)))))
>>
>> how can I output something where I can throw it into a Lyrics context and
>> have it spaced out one element per note?
>
> Oh. One element per note is tricky. How about making this a music
> function instead that outputs lyrics?
>
> diffints =
> #(define-music-function (mus) (ly:music?)
> #{ \lyricmode { $@(map ...) } #})
>
> That's what I can suggest for now. But that request seems legitimate
> enough that I'll see what it takes to make lyricmode accept a markup
> list. You'd use it presumably as
>
> \markuplist [optional duration]
Ah right. A markup list can be a markup list command, and the markup
list command code is executed at typesetting time, based on current grob
properties. The length of the markup list is not known before that
point of time, so it is hard to produce a proper expression before that.
In short, this is a lot more involved that it would appear at first
sight. One would probably use a sequential expression with an
elements-callback .
--
David Kastrup
