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

[Aaron Hill]

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.

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.  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.

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?


-- Aaron Hill