Re: LSR updates

[Phil Holmes]

----- Original Message ----- 
From: "David Kastrup" <address@hidden>
To: "Phil Holmes" <address@hidden>
Cc: <address@hidden>
Sent: Friday, July 18, 2014 2:02 PM
Subject: Re: LSR updates


> "Phil Holmes" <address@hidden> writes:
>
> > ----- Original Message ----- 
> > From: "David Kastrup" <address@hidden>
> > To: "Phil Holmes" <address@hidden>
> > Cc: <address@hidden>
> > 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