Thomas Morley <[email protected]> writes: > 2015-04-08 11:45 GMT+02:00 Thomas Morley <[email protected]>: > >> I started to rewrite chord-namings and stumbled over a problem in >> chord-generic-names.ly >> >> /Documentation/included/chord-names-jazz.ly with uncommented >> Banter-style is broken. >> At least since 2.12.3 >> >> The problem is in 'step->markup-plusminus' >> >> Here you see the old code commented and a possible patch inserted: >> >> (define (step->markup-plusminus pitch) >> (make-line-markup >> (list >> (make-simple-markup (number->string (step-nr pitch))) >> (make-simple-markup >> ;(case (step-alteration pitch) >> ; ((DOUBLE-FLAT) "--") >> ; ((FLAT) "-") >> ; ((NATURAL) "") >> ; ((SHARP) "+") >> ; ((DOUBLE-SHARP) "++")) >> (case (step-alteration pitch) >> ((-1) "--") >> ((-1/2) "-") >> ((0) "") >> ((1/2) "+") >> ((1) "++")) >> )))) >> >> case uses eqv? to compare. (guile-manual) >> (step-alteration pitch) returns: -1 or -1/2 or 0 or 1/2 or 1 >> (display (eqv? -1/2 FLAT), etc returns #t > > boiled down: > > (display DOUBLE-FLAT) > -> -1 > > (display (eqv? -1 DOUBLE-FLAT)) > -> #t > > (display > (case -1 > ((DOUBLE-FLAT) "--") > ((FLAT) "-") > ((NATURAL) "") > ((SHARP) "+") > ((DOUBLE-SHARP) "++"))) > -> #<unspecified> > > ?? > >> Thus I've no clue why the old code fails. >> Any hint?
That one's easy. As may be expected from the case-tag being in the form of an unquoted list, there is no evaluation involved. So the case statement is comparing to the symbols DOUBLE-FLAT, FLAT, etc as opposed to the values stored in the variables associated with the symbols. It would probably make more sense to define an association list for this lookup, or convert into a cond. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
