Status: Accepted Owner: ---- Labels: Type-Enhancement
New issue 2918 by [email protected]: definition of bar lines should include all span bars
http://code.google.com/p/lilypond/issues/detail?id=2918 Quoting Janek: I would imagine the user interface ("syntax") to be like this: (define-bar-line (a b c) (x y z)) or (define-bar-line ((a b c) . (x y z))) where (a b c) are the barlines (mid-system, end-of-system, beginning-of-system respectively) and (x y z) are the span barlines, in the same order as barlines. And it would be nice if (define-bar-line (a b c) (x)) was equivalent to (define-bar-line (a b c) (x x x)) Quoting Marc's answer: Thinking *a lot* more about that and trying to recode my work to fit your needs I stumbled upon quite a lot of problems: The internal structure of the properties and its names does not allow for this extension in a clean way. We have BarLine #'glyph (that's the string given by the user) and BarLine #'glyph-name (which is the string for the bar line to be drawn, i.e. after line breaking decisions). We have SpanBar #'glyph-name which is computed by ly:span-bar::calc-glyph-name and the glyph-name we use here will be that of the corresponding bar line, because we need both informations about the bar line and the span bar line to get the spacing correctly. If I store a span bar triple '(span-bar-glyph end-of-line begin-next-line), I'll have to carry the whole direction computation stuff in almost every callback, and moreover, ly:span-bar::calc-glyph-name would either return a list or the BarLine #'glyph, not the #'glyph-name, so to be 100% clean, one would have to rename the property into SpanBar#'glyph-list or SpanBar #'glyph. The whole discussion is at http://lists.gnu.org/archive/html/lilypond-devel/2012-10/msg00143.html
