Re: bar line interface / repat structure considerations

[David Kastrup]

Marc Hohl <address@hidden> writes:

> Am 13.03.2013 10:27, schrieb David Kastrup:
>
>>    One reason I am skeptical about this
>> particular suggestion is that more often than not (like the typical
>> multi-stanza pop song with a separate ending), D.S.a.C is _intertwined_
>> with a repeat volta.
> LilyPond already allows for nested repeats, but one has to
> take case for ambiguities, that's right.

"intertwined" is not just nesting.  It's more goto-like, and
instructions like "Dal segno", and "al Coda" _are_ gotos in nature.  Not
every goto-like structure can comfortably transformed into a structured
form.

>>> b) if the user writes \bar "S.S" without defining it before,
>>> LilyPond does (define-bar-line "S.S")herself, therefore
>>> allowing the user to write bar lines "on-the-fly".
>> Sounds tricky.  I am also not sure that it is a good idea to hide that a
>> particular bar type just has "best guess" support.
> Oh, sorry, I meant
>
> \bar "S.S"
>
> leads to
>
> (define-bar-type "S.S" "S.S")
>
> A warning that one uses a bar line not properly defined
> can be raised, of course.

Could even be an error.

>> Even if the user only acknowledges this by writing
>> #(define-bar-type "S.S")
>> and thus signifying "I am ok with all the default choices".
> What would you propose instead?

Uh, that's what I propose.  Force the user to at least write
#(define-bar-type "S.S") before using a bar type that LilyPond _could_
try deriving a default recipe for.

> The current interface ignores unknown bar lines (that's not
> ideal) but forces the user to define bar lines before using it.
> We can stick to that behavior and raise warnings like
>
> (define-bar-line "myBar" "S.S")
>
> "warning: you define a bar line without line breaking decisions and
> span bars.
> LilyPond uses "S.S" at the end of line and as span bar, too."

No, that makes no sense.  You warn about something that the user may
consider totally fine.  I'd accept
(define-bar-line "myBar" "S.S")
without further comment.  One could probably even accept
(define-bar-line "S.S") without further comment, but that implies a
strong suggestion of naming bar line types after their default
appearance.

On the other hand, I would not distinguish between undefined \bar "S.S"
and \bar "myBar" with regard to which deserves an error.

The error is an undefined bar type.  How LilyPond chooses to meddle on
(if at all) does not belong in the error message.

-- 
David Kastrup