----- Original Message -----
From: "David Kastrup" <[email protected]>
To: "Phil Holmes" <[email protected]>
Cc: <[email protected]>
Sent: Friday, July 18, 2014 2:02 PM
Subject: Re: LSR updates
"Phil Holmes" <[email protected]> writes:
----- Original Message -----
From: "David Kastrup" <[email protected]>
To: "Phil Holmes" <[email protected]>
Cc: <[email protected]>
Sent: Friday, July 18, 2014 1:49 PM
Subject: Re: LSR updates
With regard to LSR links one probably needs to check whether they are
(re-)introduced via makelsr or some other script if one really wants to
get rid of the bad links for good.
I've already checked that. They're put in by makelsr, but only if it
has updated the snippet, so a large number end up with the old, wrong
address.
Nothing wrong with fixing makelsr and all the links it _would_ have
created after fixing. Possibly in two commits, the second titled
"pretend we have never been running makelsr.py with bad LSR links" or
so.
The end result of those two commits should again meet the "If the user
reruns makelsr.py now, nothing really happens" criterion.
OK - running makelsr on current master does not touch any files, and they
all have the wrong address. I propose to rerun my script, only changing the
address of the LSR this time...
I'll then update the LSR itself: there are now only 7 /new snippets that
don't compile with 2.18.2, so this will slim that directory down
substantially. They are:
broken-crescendo-hairpin.ly
flat-flags-and-beam-nibs.ly
making-an-object-invisible-with-the-transparent-property.ly
modifying-tuplet-bracket-length.ly
non-traditional-key-signatures.ly
staff-headword.ly
unfretted-headword.ly
AFAICS they all fail under 2.18 because of the isolated note values.
--
Phil Holmes
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
