Re: "Mensurstriche" (barlines between systems) and Repeat signs.

[Thomas Morley]

Hi Aaron,

I'm a bit verbose below (even repeating things you already know),
because we're on the user-list and I hope more folk gets involved that
way.

Am Sa., 2. Feb. 2019 um 14:21 Uhr schrieb Aaron Hill <address@hidden>:
>
> On 2019-02-02 2:29 am, Thomas Morley wrote:
> > Am Fr., 1. Feb. 2019 um 20:19 Uhr schrieb Malte Meyn
> > <address@hidden>:
> >>
> >> Am 01.02.19 um 18:42 schrieb Aaron Hill:
> >> > That very much sounds like a bug and should be reported.  The final
> >> > argument is the span setting which should be agnostic of start and end
> >> > styles and vice versa.
> >> Hm … I don’t think that this is correct: How about
> >>         \defineBarLine ".|:-||" #'("||" ".|:" ".|")
> >> ? If the span bar ".|" would be used at all positions, the output at
> >> line breaks wouldn’t be correct: the "||" bar at the line end would
> >> have
> >> a ".|" span bar too …
> >
> > I don't see any bug [ . . . ]
>
> Allow me to elaborate on how I see \defineBarLine as potentially
> confusing given its naming and arguments:
>
> \defineBarLine doesn't actually define anything.  It is the name of the
> bar line itself that defines it.  I do not have to use \defineBarLine to
> be able to say \bar "foo".  Instead, I need only ensure there are valid
> barline-print-procedures for "f" and "o", and that process doesn't
> involve \defineBarLine at all.  All that \defineBarLine does is
> associate additional information with an already, implicitly defined bar
> line.

I don't think you're correct.

You can always try:
{ R1 \bar "foo" R1 }
with completely undefined behaviour of "foo"
-> No bar-line is printed
(The resulting programming errors are due to the use of a
MultiMeasureRest, though.)


Defining print-procedures, like

#(add-bar-glyph-print-procedure
  "f"
  (lambda (grob extent) (grob-interpret-markup grob "f")))
#(add-bar-glyph-print-procedure
  "o"
  (lambda (grob extent) (grob-interpret-markup grob "o")))

%\defineBarLine "foo" #'("f" "o" "|")

{ R1 \bar "foo" R1 }

will return the same result, "foo" is still not available.
-> No bar-line is printed

But if you uncomment the %\defineBarLine above, it works.
-> the "foo"-bar-line _is_ printed
\defineBarLine fills 'bar-glyph-alist and 'span-bar-glyph-alist,
making their entries available (printable) for the \bar-command.

Or try in a fresh ly-file:

#(set! (@@ (lily) bar-glyph-alist) '())

{ R1  R1 }

All bar-lines are gone ...

>
> One could argue that the definition of a bar line by name alone is
> incomplete so one needs to use \defineBarLine, but in actuality the
> implementation has default values for spanning behavior and line
> breaking behavior.  \defineBarLine is there to replace these default
> values.

Well, the default values are set by define-bar-line or defineBarLine
in the relevant alists.
Defining a print-procedure and assigning a glyph to it as done by
'add-bar-glyph-print-procedure' means that the alist
'bar-glyph-print-procedures' is filled.
Without calling define-bar-line or \defineBarLine (for me it's almost
the same) nothing is available/printable.

Both, the schemish define-bar-line or \defineBarLine may be used to
get modified bar-lines, bar-line-variants or complete new bar-lines
(needs some more preluminary work, ofcourse)

Currently defineBarLine or it's scheme-sibling says:
For \bar "string0" behave
  like "string1" at line end
  like "string2" at line-start
  like "string3" for the span-bar

string0 to 3 should have printing-procedures, ofcourse.

I don't see anything wrong here.

One could think of:
\defineBarLine
  "name"
  #'(string1 string2 string3) %% for the behaviour of BarLines (end,
middle, start of line)
  #'(string4 string5 string6) %% for the behaviour of the SpanBars
(end, middle, start of line)

But I have a hard time seeing this as an improvement lol

Though, we're now at the topic how to improve the user interface.
Here some work could be done, admittedly.
(I remember David K. complained as well, some time ago ...)

> Perhaps the naming could be improved, but given my limited time
> I am struggling to come up with a better verb than "define" that evokes
> the correct idea better enough to justify a name change.
>
> The second argument to \defineBarLine is a list of three strings,
> however the purpose and interpretation of those strings is not
> identical.  The first two elements are related to line breaking so there
> is rationale to group them in a list, but the third is completely
> unrelated as it deals with spanning behavior.  The first two elements
> are names of other bar lines that are substituted at line breaks,
> whereas the third is read only a series of symbols used to define the
> shape and look of the span.  Again, the third element does not seem to
> belong in a list with the others.
>
> Seeing this list of three strings that by all outward appearances look
> related, their purpose and interpretation is muddled.  In this
> particular instance, I did not immediately realize the line breaking
> values are intended to result in additional lookups for determining
> spanning behavior; although it does make perfect sense now.  We might
> not want to have the same spanning behavior at the line breaks as we do
> with the bar line in the middle of a line.  But why then is the spanning
> behavior placed so far away from the named bar line whose definition is
> being refined, and why is it grouped with the line breaking behavior to
> which it is otherwise agnostic?
>
> Would it be worth considering a refactoring of the \defineBarLine
> function to keep concerns better separated?  Consider:
>
>      \defineBarLine "bar" #'("end" "begin" "span")
>      % becomes
>      \defineBarLine "bar" "span" #'("end" "begin")
>
> Here the spanning behavior is clearly more closely associated with the
> bar by its proximity to the name of the bar line.  The line breaking
> values are still grouped in a list to continue to provide a visual
> reminder of their related purpose but are kept away from the bar line
> name.

This can be reached easily with:

defineBarLine =
#(define-void-function (bar span end-start-line-pair) (string? string? pair?)
  (define-bar-line
    bar (car end-start-line-pair) (cdr end-start-line-pair) span))


\defineBarLine "|" "!" #'("S" . "k")

m = {
  R1 R1 \break R1 R1 R1
}

\new StaffGroup << \m \m >>

I'm not sure it's really better, opinions?

>
> Alternately, the \defineBarLine function could be split:
>
>      \defineBarLine "bar" #'("end" "begin" "span")
>      % becomes
>      \setBarLineSpanning "bar" "span"
>      \setBarLineBreaking "bar" "end" "begin"
>
> We gain some clarity and self-documentation; and in fact, the line
> breaking arguments no longer need to be grouped in a list.  Users who
> only need to change the default behavior for one aspect need only use
> its associated function.  But would the added verbosity be a justifiable
> cost?

I think this suggestion would need a bit more work.
Not sure it's worth the afford. But that's only me. I was involved in
coding this scheme-interface, so I'm familiar with most of it (albeit
not all). It's always difficult to write a good user-interface or
documentation, if one is too familiar with things...
So I'm open for suggestions as well.
Currently I haven't researched the possibilities of setBarLineSpanning
etc in depth maybe later or tomorrow, I may change my mind then ...


Cheers,
  Harm