Feature request: Jump to type definition

[macraig]

User at https://app.hubspot.com/contacts/2762526/company/464956351/ requested a "Go to type" feature.

[efritz]

The LSIF spec has a typeDefinition concept that is distinct from definition and references.

Implementing this should be prioritized and the technical work would include:

• Emitting this data in indexers. Effort depends on each language for which it makes sense. Starting with lsif-go would be likely a few days of effort and a good start as the company requesting this feature wants it for Go specifically.
• Updating the LSIF worker to accept this new information and store it in the bundles
• Adding additional LSIF GraphQL endpoints that will query the backend
• Updating the UI to show a "Go To Type" action button (cc @sourcegraph/web)
• Implementing the providers in the code intel extensions

[alidn]

Hi!

For step 1, I submitted a pull-request to lsif-go to emit type-definition data: sourcegraph/lsif-go/pull/127

I could work on step 2 & 3 once that PR is accepted (or maybe even before that), but I'm not sure if I can run an enterprise account locally to test it.

In the meanwhile, I will keep working on that PR if that's ok?

[macraig]

Hi @alidn, thanks for opening the PR! We're really excited to have more people contributing to our code intelligence efforts! Once the steps in sourcegraph/lsif-go/pull/127 are complete the team would happily review and merge it.

[felixfbecker]

Updating the UI to show a "Go To Type" action button

FYI We've had this in the past with language servers but it was removed because it created too many buttons in the hover. When a type provider is registered, it is shown in the "TYPE" tab of the panel when first invoking Find References to open the panel I believe.

[alidn]

Thank you María, I'll resume working on the PR.

For the UI, is there a reason why a custom right-click menu is not considered? That will become even more useful once you support go-to-implementation, call-hierarchy, etc.

[efritz]

cc @sourcegraph/web Has there been a request for this feature before? @felixfbecker A menu like that could make the "too many buttons" problem go away.

[felixfbecker]

That's essentially what IDEs like VS Code do, but on the web it's not as common of a pattern to override the right click action (on most websites, and perhaps in the expectation of many people, it brings up the browser menu with entries like "Copy link address", "Open in new tab", browser extension actions etc). That's why we have buttons in the hover menu unlike IDEs. Not saying what we have is perfect, just sharing the historical considerations.

We support go-to-implementation BTW from an extension API perspective the same way as go-to-type.

[alidn]

That makes sense. The reason I suggested that was it works very well for me in this tool: https://cs.opensource.google/go/go/+/master:src/net/http/fs.go

It avoids the problems you mentioned by:

1. Only overriding the menu if the cursor is on a symbol, so the users can still use the default menu.
2. Including both "Copy link address" and "Open in new tab" in the custom menu.

What do you think about that as an option?

[macraig]

Moving feature request to Productboard