Direct users to gotools.org instead of GitHub for viewing source.

[emidoots]

From @slimsag on January 18, 2015 1:22

When clicking on a data type, function, etc on an Azul3D package at godoc.org -- we have the ability to send the user to a place for viewing the source code of that symbol.

Today, we send users to GItHub's source view. gotools.org is much nice and more appropriate as it offers great symbol lookup searching abilities.

• gotools.org supports symbol names in the URL pattern.
• godoc.org does not support symbol names in go-source meta tags.

We currently have no way to connect the two together (without just dumping the user at the top of the gotools.org/azul3d.org/semver.v1 page and having them find the relevant source themselves).

Copied from original issue: azul3d-legacy/issues#36

[emidoots]

@shurcooL what are your thoughts on this issue, out of curiosity?

[dmitshur]

I think that'd be pretty cool. So far the gotools.org server is pretty underloaded, so it'd be great to see it serving some larger repos and see how the experience is. It has had great uptime, so I'm okay with someone trying to rely on it (rather than using it for ad-hoc queries).

Since you have control over this and can change it whenever, it seems low risk to try. My only ask is if it needs to be disabled either because of problems, or because of a bad user experience, that you open an issue in the gtdo tracker and report it (rather than ignoring it), so I can be aware. :)

So 👍 from me.

That said, did you do something to resolve azul3d/website#11? Because I thought that the GNUTLS thing was a blocker in the past, but https://gotools.org/azul3d.org/engine seems to work fine now.

[emidoots]

Great! And I absolutely would report any issues obviously :)

You mention it is a low-cost switch.. is it actually possible to specify the line number to jump to in gotools.org for the go-source meta tag? last I remembered this wasn't possible (I'm probably wrong though).

That said, did you do something to resolve azul3d/website#11? Because I thought that the GNUTLS thing was a blocker in the past, but https://gotools.org/azul3d.org/engine seems to work fine now.

Indeed, not just that, but https://godoc.org/azul3d.org/engine also works. It seems that the GNUTLS error was somehow in relation to our git interception code, which would modify the default git branch for git clone operations (semver package did this). Now that it's gone, everything seems to work!

[dmitshur]

It seems that the GNUTLS error was somehow in relation to our git interception code, which would modify the default git branch for git clone operations (semver package did this). Now that it's gone, everything seems to work!

Cool, I'm glad that simplification led to an improvement here!

[dmitshur]

You mention it is a low-cost switch.. is it actually possible to specify the line number to jump to in gotools.org for the go-source meta tag? last I remembered this wasn't possible (I'm probably wrong though).

Ok, it's documented here:

https://github.com/golang/gddo/wiki/Source-Code-Links

You could use {file} and {line} to arrange it to point to the right place. gotools supports both line-based links, as well as identifier-name-based ones.

Until shurcooL/gtdo#27 is resolved, using identifier names is not 100% reliable when a package has multiple identifiers with same name (for example, as a consequence of build tags, or multiple init funcs), but it does work in a vast majority of cases.

I made a proposal here to add something like {name}, and the response was that it should be a separate issue/PR. That hasn't happened yet, but it can in the future.

If you're okay with using file and line-based system, I believe the meta tag would look like this, adjusted for import path of course:

<meta name="go-source" content="rsc.io/pdf https://gotools.org/rsc.io/pdf#{file}-L{line}" />

However, even that is not going to quite work out of the box, because the dots in filename get escaped to dashes. E.g.:

https://gotools.org/rsc.io/pdf#read-go-L79

But the template I've suggested would point to:

https://gotools.org/rsc.io/pdf#read.go-L79

I was considering allowing dots in hashes for a while, so this might be a good reason to make that change. Implementation wise, it's trivial.

[emidoots]

After discussion with @shurcooL on Slack we hammered out all the details and he did an awesome job fixing a few bugs to make this work and it's all live now. Clicking on any jump-to-source links on godoc.org for Azul3D now brings you to gotools.org -- enjoy!