PATCH: allow source: TracLinks with line number but no revision

[hyugaricdeau@…]

Currently, to include a line number in a link, the revision also has to be specified, for example: [source:/path/to/file@3#L5]. However, a link like [source:/path/to/file#L5] will end up linking to the file at revision 5. This is just a simple change to the regexp used.

[Christian Boos]

The idea was to make the revision mandatory on purpose, as a line numbers aren't good for permanent reference, i.e. what's at line 100 at rev. 1000 will probably have nothing to do with what's at line 100 at rev. 2000.

If you really want to refer to the last revision of a file, you can use @head.

But I'm open to other opinions.

Note also that at least for 0.10, we must still support the source:file#rev (deprecated) syntax.

[hyugaricdeau@…]

I see—I had some users complaining about this, and thought it might be a bug, as I wasn't sure about the rationale. But this makes sense, and I'll pass your points along. I also didn't realize that source:file#rev was actually correct, albeit deprecated syntax.

I still wonder if there isn't a better solution. But I'll have to think about it.

[Christian Boos]

We could support source:file#rev and source:file#Lxyz (with xyz a line number) at the same time, and in the latter case use the youngest rev, so it's not a technical issue, it's more that we don't want to encourage creating links that will most certainly become non-sense over time.

In the few cases where you're pretty sure the meaning of a line number will remain the same over time (near top of the file, source file below /tags, or nearly frozen branches, etc.), you could still use @head.

Someone also proposed being able to link to function name or class names within source files, and I think that's a good idea, which I still keep in mind for doing later, when we implement the necessary infrastructure to post-process the result of code highlighters (see #1520 and #1292).

[Christian Boos]

The way to allow source: TracLinks with line number but no revision suggested in #3745 addresses the concerns I've expressed above, so I'm closing this one as duplicate.