Re: Line breaks in @file{} entries?

[Valentin Villenave]

On Fri, Nov 26, 2010 at 8:44 AM, Trevor Daniels <address@hidden> 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.