On 2019-02-02 2:29 am, Thomas Morley wrote:
Am Fr., 1. Feb. 2019 um 20:19 Uhr schrieb Malte Meyn
<lilyp...@maltemeyn.de>:
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
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user