[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Further problems with makeLSR
From: |
David Kastrup |
Subject: |
Re: Further problems with makeLSR |
Date: |
Fri, 02 Nov 2012 16:41:56 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) |
"Phil Holmes" <address@hidden> writes:
> From: "David Kastrup" <address@hidden>
> To: <address@hidden>
> Sent: Friday, November 02, 2012 3:24 PM
> Subject: Re: Further problems with makeLSR
>
>
>> "Phil Holmes" <address@hidden> 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
- Further problems with makeLSR, Phil Holmes, 2012/11/02
- Re: Further problems with makeLSR, David Kastrup, 2012/11/02
- Re: Further problems with makeLSR, Phil Holmes, 2012/11/02
- Re: Further problems with makeLSR,
David Kastrup <=
- Re: Further problems with makeLSR, Phil Holmes, 2012/11/02
- Re: Further problems with makeLSR, David Kastrup, 2012/11/02
- Re: Further problems with makeLSR, Phil Holmes, 2012/11/02
- Re: Further problems with makeLSR, David Kastrup, 2012/11/02
- Re: Further problems with makeLSR, Phil Holmes, 2012/11/02
- Re: Further problems with makeLSR, Phil Holmes, 2012/11/02