Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/gopls: consider adding special cases for main Go tree and golang.org/x modules when linkifying issues #46245

Open
dmitshur opened this issue May 18, 2021 · 3 comments

Comments

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented May 18, 2021

@heschi pointed out to me that gopls has a feature of turning text like org/repo#123 into links to corresponding GitHub issues.

The main Go repository and most (if not all) golang.org/x modules use the main Go issue tracker (https://golang.org/issues) and have many¹ existing comments that refer to Go issues as just "#​123" or "issue 123".

If it's deemed okay to add special cases to that behavior for the Go project itself, this is a feature request to adjust the linkifying behavior of gopls to recognize when the module path is something in the standard library (just std, cmd would go a long way) or has a golang.org/ prefix, and not require the "golang/go" prefix. That would help make existing comments useful and reduce the desire to be adding the otherwise-not-strictly-needed "golang/go" prefix in Go comments.

¹ (Details)

A quick grep in the Go tree at commit a2c07a9:

"see issue \d+"  - 286 matches
"see issue #\d+" - 143 matches
"see #\d+"       - 82 matches
"golang/go#\d+"  - 5 matches

CC @stamblerre, @heschi.

@findleyr
Copy link
Contributor

@findleyr findleyr commented May 19, 2021

If we're going to do this, couldn't we equally well add support for any module path that is a subpath of github.com/<user>/<repo> (i.e. resolve #123 to github.com/<user>/<repo>/issues/123)?

Of course we'd still need special handling for golang.org modules.

@dmitshur
Copy link
Contributor Author

@dmitshur dmitshur commented May 19, 2021

Yes, I think that would be possible too, although there may be some edge cases that couldn't be handled easily. For example, GitHub forks, or repositories with custom module paths (module example.com/m) whose source code lives on github.com.

If considering GitHub, might want to also consider other common code hosting sites that cmd/go already knows about and their issue trackers. Of course such work would be larger and should be tracked in separate issue(s), so this one can be remain about just the Go project.

@stamblerre stamblerre removed this from the Unreleased milestone May 19, 2021
@stamblerre stamblerre added this to the gopls/unplanned milestone May 19, 2021
@heschi
Copy link
Contributor

@heschi heschi commented May 19, 2021

We could consider keying off of codereview.cfg as a (theoretically) less special case than golang.org import paths, but AFAIK literally nobody else uses git-codereview.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants