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

"Go to symbol in editor" in Code does not work if built-in TS disabled #271

Open
chriskrycho opened this issue Feb 28, 2022 · 4 comments
Open
Labels
bug Something isn't working good first issue Good for newcomers

Comments

@chriskrycho
Copy link
Member

chriskrycho commented Feb 28, 2022

The editor command workbench.action.gotoSymbol, also trigger-able as "Go to symbol in editor", does not work when the built-in TS support is disabled. This appears to be something like an unimplement LSP method, perhaps?

@chriskrycho chriskrycho added bug Something isn't working good first issue Good for newcomers labels Feb 28, 2022
@dfreeman
Copy link
Member

This appears to be something like an unimplement LSP method, perhaps?

Confirmed! We have a handler for onWorkspaceSymbol but not onDocumentSymbol here.

I would guess the trickiest part of fixing this may just be figuring out what the corresponding method on ts.LanguageService is, since their nomenclature is often wildly different from the general protocol (e.g. a WorkspaceSymbol request corresponds to the getNavigateToItems() method on the service itself 😅).

Beyond that, it should be straightforward to implement following the pattern set several similar calls, if someone has the inclination to look into fixing this!

@dfreeman dfreeman removed good first issue Good for newcomers labels Jul 1, 2022
@dfreeman
Copy link
Member

dfreeman commented Jul 1, 2022

I looked into this briefly, and the corresponding ts.LanguageService method is getNavigationTree(), which does in fact return a tree structure rather than a flat list of symbols—it turns out the same LSP call that powers "Go to symbol in editor" (formally, a DocumentSymbol request) also powers the "Outline" pane that many editors have.

What makes this particularly tricky is that editors (or at least Code) don't handle it super well when multiple language servers support that request, and you end up just having multiple roots in your Outline pane with lots of overlapping content, and duplicate entries in the "Go to symbol in editor" list.

I suspect the long-term answer here is probably making glint-language-server slightly more aware of the environment it's operating in, so we can always respond to DocumentSymbol requests for files that tsserver ignores (e.g. .hbs or .gts ones), while only responding to those requests for .ts files if we know that tsserver isn't already doing it.

@dfreeman
Copy link
Member

None of those are related. The comment above yours explains the LSP method we aren't implementing for any source type

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants