[Lilypond-auto] Issue 2918 in lilypond: definition of bar lines should include all span bars

[lilypond]

Status: Accepted
Owner: ----
Labels: Type-Enhancement

New issue 2918 by address@hidden: 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