[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: upgrading a songbook from 2.14 to 2.18
From: |
David Kastrup |
Subject: |
Re: upgrading a songbook from 2.14 to 2.18 |
Date: |
Wed, 02 Sep 2020 12:13:54 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Maurits Lamers <maurits@weidestraat.nl> writes:
> Hi all,
>
> In order to have my braille generator not have to support Lilypond 2.14 I
> tried to upgrade my music library I am building this braille generator on.
>
> However, because of (a lot of) specific "hacks" on the layout, simply running
> convert-ly on the entire library doesn't completely finish the job.
> These overrides use a specific syntax to distinguish between the scheme part
> and the lilypond part, also inside function definitions.
> The following function is an example of this. It is defined as a scheme
> function, but uses Lilypond syntax inside which is put between #{ and #}.
>
> These kind of definitions seem to cause all kinds of issues.
> One of these issues can be found in a piece of code taken from the
> lilypond-user mailing list
> (https://lists.gnu.org/archive/html/lilypond-user/2011-03/msg00270.html
> <https://lists.gnu.org/archive/html/lilypond-user/2011-03/msg00270.html>) of
> which I will only include the start:
>
> ====
>
> alignGrob =
> #(define-music-function (parser location grob-to-align reference-grob dir
> corr) (string? symbol? integer? number?)
> #{
> \overrideProperty $grob-to-align #'after-line-breaking
> #(lambda (grob)
> (let* ((sys (ly:grob-system grob))
>
>
> ====
>
> The lambda expression on the fifth line of this definition causes a "warning:
> ignoring non-musical expression".
>
> Another example is in the function below.
>
> ====
>
> stanza = #
> (define-music-function (parser location str)
> (string?)
> #{
> \set stanza = #
> (markup #:stanza-number
> (string-append $str "")) #})
> ====
>
> In this function, the line with '\set stanza causes an GUILE error:
> "unbound variable str" wherever this function is applied.
convert-ly does text replacements. It is not a full parser. If text
replacements are supposed to work, you need to write your text in a way
that the replacement patterns cover. Stuff like putting # on one line
and a corresponding opening paren on the next line are just too weird
for those writing the conversion rules to have foreseen.
So first try formatting your source in a somewhat common manner and then
try running convert-ly.
--
David Kastrup