Kaj Persson <[email protected]> writes: > Den 2017-03-23 kl. 17:27, skrev Mats Bengtsson: >> Well, by default, the \mark command is defined as (in >> .../ly/music-functions-init.ly) >> >> mark = >> #(define-music-function >> (label) ((number-or-markup?)) >> "Make the music for the \\mark command." >> (let* ((set (and (integer? label) >> (context-spec-music (make-property-set >> 'rehearsalMark label) >> 'Score))) >> (ev (make-music 'MarkEvent >> 'origin (*location*)))) >> >> (if set >> (make-sequential-music (list set ev)) >> (begin >> (if label (set! (ly:music-property ev 'label) label)) >> ev)))) >> >> >> If you copy this definition into the top of your file and replace >> 'Score by 'Staff, it should behave as you expect. >> >> /Mats >> >> > Thank you Mats! Well, I haven't tested this, and do not find much > reason to do so neither. Shouldn't the routine adapt itself to the > context it is defined in? Some kind of variable? In the "Notation > Reference" there is no hint of having to change the code when you move > an engraver to a new context. Well I do not know Scheme (yet), and do > not see that an ordinary user should have to (even if I can imagine it > might raise the understanding a wee).
I agree. Tracker issue: 5105 (https://sourceforge.net/p/testlilyissues/issues/5105/) Rietveld issue: 316360043 (https://codereview.appspot.com/316360043) Issue description: Allow number as MarkEvent.label This puts all Mark counter handling in the hand of the Mark_engraver . Interestingly, Mark_engraver itself already was perfectly equipped to dealing with that, but the `label' property did not yet accept numbers. Also contains commits: More \mark tests for \displayLilyMusic Let \displayLilyMusic accept numbered marks Let \mark warnings show input location Let's see whether the regression tests turn up any thinkos of mine. This strange behavior was inherited directly from the original code in the parser when I changed \mark to a music function in 2011. Interestingly, \displayLilyMusic \mark #3 hasn't displayed \mark #3 for a long time, possibly forever. -- David Kastrup _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
