Make switching between external reference-view and internal reference-view more feasible #146037
Labels
insiders-released
Patch has been released in VS Code Insiders
polish
Cleanup and polish issue
references-viewlet
Milestone
TL;DR
See the Requests section.
Background
Currently, vscode-java supports Type Hierarchy in its own way (not standard LSP) and use the reference-view API to show the result. Since Type Hierarchy has been supported in vscode, reference-view and language-client, we are trying to migrate our current implementation to LSP based and there is a PR in progress.
About the implementation in reference-view, we had a discussion in #126666. Now we can successfully migrate our UI implementation of supertype and subtype view to the [type hierarchy implementation] (https://github.com/microsoft/vscode-references-view/tree/main/src/types) in reference-view. However, for vscode-java, there is an extra Class Hierarchy view is not supported in reference-view and LSP. We want to implement it ourselves via reference-view API and find some gaps here.
Gaps
We can successfully register our own Class Hierarchy view and show it.
You can see we can switch to other view in vscode-java current implementation. either in the view title or in the item menu.
When migrating to LSP implementation, we encounter some difficulties in switching the Class Hierarchy view (implemented in vscode-java) and the Supertype/Subtype Hierarchy view (implemented in reference-view).
Switch from Class Hierarchy view (in vscode-java) to Supertype/Subtype Hierarchy view (in reference-view)
We need to execute command
references-view.showSupertypes
orreferences-view.showSubtypes
to switch the view. We can offer the right location as an anchor, but the current implementation only receivesTypeItem | unknown
. We'd like to change this behavior to accept a vscode.Location as an anchor as well. (Actually, all we need here is the location)Switch from Supertype/Subtype Hierarchy view to Class Hierarchy view
We can call our constructors to create a new Class Hierarchy view, but we don't have the current anchor information from current reference-view. The reference-view API only exposes
setInput()
method. If there is any api likegetInput(): SymbolTreeInput
then we can get the current anchor viaSymbolTreeInput.location
.Requests
on the opposite side of current setInput().
@jrieken do you think it make sense? If so, I can create corresponding PRs in the reference-view repository.
The text was updated successfully, but these errors were encountered: