[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lilypond-user
Subject:    renumber idea (Re: ANN: python-ly 0.1 (the "ly" tool))
From:       Wilbert Berendsen <wbsoft () xs4all ! nl>
Date:       2014-01-07 8:14:34
Message-ID: 52CBB76A.1030505 () xs4all ! nl
[Download RAW message or body]

op 07-01-14 08:40, Johan Vromans schreef:
> Wilbert Berendsen <wbsoft@xs4all.nl> writes:
>
>> a first release of the command-line ly tool with the Python ly library
>> is out:
> Yay!
>
> Given a (section of) .ly with barchecks and line number comments, e.g.
>
>    d16  c8.~  c4  r2   |  % 9
>    \bar "||"
>    R1  |  % 10
>    R1  |  % 10
>    R1  |  % 12
>    e4  e8  e16  f16~  f8.  c16  f8  e8   |  % 13
>
> can ly recalculate the line numbers? For example, in Emacs, select a
> section and then
>
>    C-u M-| ly "renumber;start=8"
>
> would result in
>
>    d16  c8.~  c4  r2   |  % 8
>    \bar "||"
>    R1  |  % 9
>    R1  |  % 10
>    R1  |  % 11
>    e4  e8  e16  f16~  f8.  c16  f8  e8   |  % 12
>
>
Yes, that would be feasible. But you would need to write 
"start=8;renumber" or -d start=8 renumber, as otherwise the start 
variable is set to 8 after the command has been performed.

Although the | % <number> is a convention, and ly is mainly intended to 
perform operations that really can't be done by some other intelligent 
editor algorithm. ly also excepts a semantically complete LilyPond 
input, i.e. it can parse "\relative { c d e f g }", or "{ c d e f g }", 
but not "c d e f g", as pitch names aren't written in the toplevel 
LilyPond context.

I am planning support for auto-inserting, and checking, bar checks. That 
tool could then have an option to add numbered comments.

But this idea raises another idea: The ly utilities are perfectly 
capable to operate on ranges, they also do that inside Frescobaldi.

So when calling ly from an external editor, and intending for it to 
operate on some selected range, the best way would be that ly still is 
fed the whole text input, but that some command or variable would 
restrict the range to operate on (e.g. "select" the fragment to be 
manipulated).

Support for selecting a range before calling a command is planned.

Best!
Wilbert


[prev in list] [next in list] [prev in thread] [next in thread]