"Phil Holmes" <[email protected]> writes: > From: "David Kastrup" <[email protected]> > To: <[email protected]> > Sent: Friday, November 02, 2012 3:24 PM > Subject: Re: Further problems with makeLSR > > >> "Phil Holmes" <[email protected]> writes: >> >>> I've had another go at running makeLSR to update the snippet lists, >>> and this time it seems to be reverting changes David made. An >>> example: >>> >>> diff --git >>> a/Documentation/snippets/adding-a-figured-bass-above-or-below-the-not >>> index cfe71cb..6e15690 100644 >>> --- >>> a/Documentation/snippets/adding-a-figured-bass-above-or-below-the-notes.ly >>> +++ >>> b/Documentation/snippets/adding-a-figured-bass-above-or-below-the-notes.ly >>> @@ -4,7 +4,7 @@ >>> %% and then run scripts/auxiliar/makelsr.py >>> %% >>> %% This file is in the public domain. >>> -\version "2.17.6" >>> +\version "2.16.0" >>> >>> \header { >>> lsrtags = "ancient-notation, chords, contexts-and-engravers" >>> @@ -32,11 +32,11 @@ bass = { >>> } >>> continuo = \figuremode { >>> <_>4 <6>4 <5/>4 >>> - \override Staff.BassFigureAlignmentPositioning.direction = #UP >>> + \override Staff.BassFigureAlignmentPositioning #'direction = #UP >>> >>> makeLSR runs convert-ly, and this seems to be replacing the 2.17.6 >>> version number with 2.16.0 and reverting the change to the dot or hash >>> syntax. It looks as though convert-ly is not picking up the rule to >>> update this syntax properly. Anyone any idea why? >> >> Oh rats. The problem would be that any changed snippets need to be >> copied to snippets/new (after editing their headers appropriately) in >> order not to be overwritten by LSR. >> >> And, of course, after the latest change this concerns a sizable number >> of snippets. We need to get this done before the next LSR update. >> Anybody up for it? > > I think that _might_ not be necessary. If it's possible to update > them with a convert-ly rule, they should not need adding to > snippets/new.
Obviously that does not help since all of the affected snippets were actually changed with convert-ly. > Otherwise, we'll end up with too many snippets in /new to be > comfortable with. Where does the comfort level derive from? > Alternatively - does the older syntax still work? _Some_ of the older syntax continues to work (namely that for \override/\revert). But I don't see that presenting an inconsistent view would make any sense here. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
