On Fri, Nov 26, 2010 at 8:44 AM, Trevor Daniels <t.dani...@treda.co.uk> wrote: > I'd prefer this patch to be reverted. That way the information about > the long filenames that previously contained @/s is retained, making > it easier to change these to @examples (if this is indeed desirable).
Hmm, tricky. I get your point: in some sense, information has been lost. How really relevant was that information, however? There were some long filenames with @/ others without, and it wasn't even consistent between translations of a same file. In many files, slashes and dashes were "escaped" in the @seealso section, *but* not in the main text where these are actually needed! Besides, as I said, this patch doesn't just add @/ everywhere, it also adds quite a bunch of @file{} items (in many places where @code{} was previously used, or even nothing at all -- for example, have a look at the modifications in input.itely: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=1b832d794f1444033f10465971e97d33f76fe310#patch42). I'm sure I can remove @/ and filter "long-ish" filenames with a regexp if needed. As Graham said, we're at the "discussing policy" stage, so I'd rather keep my commit and then bake a regexp that will apply said policy consistenly throughout the files. (That being said, even if you guys revert this commit I can still work on the modified code on a local branch, and re-push it after applying whatever regexp does the trick. But I'm afraid merging it with an up-to-date master branch afterwards, won't be a walk in the park.) Cheers, Valentin. _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel