On Oct 17, 2011, at 12:49 PM, Neil Puttock wrote: > On 17 October 2011 11:41, Graham Percival <gra...@percival-music.ca> wrote: >> On Mon, Oct 17, 2011 at 08:09:02AM +0100, Neil Puttock wrote: >>> On 17 Oct 2011 07:56, "Peekay Ex" <pkx1...@gmail.com> wrote: >>> >>>> However, and this is for Phil: could we not simply 'deprecate' the >>>> snippet(s) like we do with any that won't work (properly) in later >>>> versions, and actually I think it was Mike that a week or so ago >>>> pointed one out to me that was deprecated as of 2.14.x, because the >>>> snippet said 'I am deprecated' in the compiled the docs. Then >>>> eventually I just went back and removed the @snippet ref. >>>> >>>> Sounds pretty standard stuff. >>> >>> The CG's pretty clear on this. If the snippets are still valid, the correct >>> approach is to move them to snippets/new, with appropriate changes for new >>> syntax. >> >> If the snippets can be automatically converted by convert-ly, then >> don't touch snippets/new/. We run convert-ly for every lsr import >> for precisely this reason. > > Quite, but I understood from Mike that the convert rule doesn't work > for these snippets. >
No, it's not that - sorry for not being clear. It's that I thought the LSR imports happened periodically (along with the convert-ly rules) and that they didn't need to be incorporated into patches. The convert-ly rules should work perfectly on the file, but if they're run twice on the file (which was my concern - that I would run it once and then it'd be run again during the LSR import), then extra Flag #'transparent calls will be printed. Cheers, MS _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
