Thomas Morley <[email protected]> writes: > 2016-08-28 15:56 GMT+02:00 David Kastrup <[email protected]>: >> Thomas Morley <[email protected]> writes: >> >>> 2016-08-28 15:13 GMT+02:00 David Kastrup <[email protected]>: >>>> Thomas Morley <[email protected]> writes: >>> >>>>> ;; Question >>>>> ;; why this mapping? Obviously `text' selects from this list, but why? >>>>> --harm >>>>> (texts >>>>> (map >>>>> (lambda (x) (ly:music-property x 'text)) >>>>> (extract-typed-music m 'text-script-event))) >>>>> (text (if (null? texts) #f (if omit-root (car texts) texts)))) >>>>> (cons (if omit-root (cdr normalized) normalized) text))) >>>> >>>> Hm? This looks for text scripts and takes the first one (if any) if >>>> omit-root is set (because of available rest arguments) or otherwise all >>>> scripts. >>> >>> Well, I used some "newer" features like `extract-typed-music' to >>> rewrite the code from chord-name.scm, keeping all the original's >>> functionality. >>> But why is this functionality there at all? >> >> Which functionality? >> >>> In other words: I can't imagine a use-case where it matters. >> >> Where what matters? What exactly in the code and/or the arguments it >> interprets seems strange or (currently?) unused to you? > > Sorry, not being exact enough.
Well, at least not for getting additional input where one could work out the problem in a manner where you feel confident about what to do. And that seems like the most likely course leading to changes. At the current point of time, I can pretty much follow what the code does but without much of a clue how that fits into what needs to be done (or might need to be done). So if you have a problem with what the code does, I'm pretty sure I can fill in any blanks as long as I know what the blanks are. But with regard to what we would _want_ it to do, I'd need quite a bit more work. And if it is I who invests that work, this is likely to end up in a bit of "not invented here" syndrome where I form an opinion what to do that is not particularly compatible with anybody else's. >> Particularly if we want to replace this interface with a scheme function >> (in LilyPond syntax) we need to figure out which parts of it are not >> likely to see use anyway. > > > Agreed. > > I'll do some more research and try to clear my thoughts, before coming > back to this topic. That would be great. -- David Kastrup _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
