[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bar line interface / repat structure considerations
From: |
Janek Warchoł |
Subject: |
Re: bar line interface / repat structure considerations |
Date: |
Wed, 13 Mar 2013 17:05:08 +0100 |
Hi Marc&all,
On Wed, Mar 13, 2013 at 10:09 AM, Marc Hohl <address@hidden> wrote:
> make
> sure you sit comfortable and have a nice cup of coffee, tea or whatever
> around...
these words actually reminded me that i had a tea waiting, and thanks
to you it didn't get totally cold before i drank it :)
> a) replace the current mechanism by a command
> (define-bar-line <shortcut>
> (<bar-glyph> :prebreak <prebreak-glyph>
> :postbreak <postbreak-glyph>
> :span-bar <span-glyph>
> :prebreak-span <pre-span>
> :postbreak-span <post-span>))
>
> where :prebreak, :postbreak, :spanbar, :prebreak-span and :postbreak-span
> arguments are optional,and we define (in quasi-Lua syntax :-)
>
> <prebreak-glyph> = <prebreak-glyph> or <bar-glyph>
> <postbreak-glyph> = <postbreak-glyph> or #f
>
> <span-glyph> = <span-glyph> or <bar-glyph>
> <pre-span> = <pre-span> or <prebreak-glyph>
> <post-span> = <post-span> or <postbreak-glyph>
I like this, except that i'm not sure whether the keywords :prebreak
:postbreak etc don't clutter the view too much.
> 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".
I like this. I saw that David has some objections, so i don't insist,
but i'm pretty sure that beginners would appreciate this a lot.
> During the development of the current interface, Harm proposed some
> very tricky mechanisms where LilyPond kind of guesses what the user
> wants to achieve, so repeat signs were handled quite properly out of
> the box (including their span bar apperance), but IMHOweshould not try
> to make the bar line interface too clever.If a user wants a more
> sophisticated bar line, he/she probably knows how the span bars and
> line breaking decisions should look like without the needd to fight against
> some automatic trickery.
I agree that the guessing shouldn't get overly complicated.
thanks,
Janek
Re: bar line interface / repat structure considerations,
Janek Warchoł <=