Go to symbol in Editor should have a way to include inherited symbols

[rgrunber]

One piece of functionality that would be nice to have with VS Code Java is the ability to quickly see all inherited methods of a class that is opened. I can see the ones it declares only. The closest existing functionality would be the Go to symbol in Editor command. This is often useful when exploring some class that has a deeper inheritance structure.

Eclipse has this behaviour through the Quick Outline (<ctrl> + o), when triggered twice, which will additionally show all members that are inherited by the opened type. The outline takes into account cursor positions so it can show an outline for nested classes while completely ignoring the other elements in the document.

[Massinissab]

It would be also nice to have the capability to call the "call hierarchy" action directly from the method listed in the outline.

[gayanper]

Today in vscode there is no way to view the symbols including the parents symbols.

Even though this is not a UI only solution, not having the possibility in the UI to switch between document symbols vs all symbols of the document hierarchy and language server protocol not having support to pass in such mode put all LSP implementation to just send the document symbols.

Therefore what if we could support our own symbol chooser which will include inherited symbols as well. I think not having this support in all editors out there won't be a big issue, but if they really need they can implement the support if we add it to java lsp extensions.

@rgrunber WDYT ?

[rgrunber]

I'm fine with making this a mostly UI-specific change to vscode-java. After all, the only thing we should do on the language server side is augment the DocumentSymbolParams to have an optional boolean includeInheritted. Either that or just create a separate method in the protocol for our need.

Is it possible to override the document symbols quick-pick menu ?

Also, the closest thing I could fine was microsoft/vscode#86761 , which is something along the lines of "there should be more control over what symbols appear" . I noticed in there that in the editor symbol search quick-pick, if you type an : (after the @ that defines the search), it seems to categorize the symbols. Haven't seen this documented, but I wonder if we can override the search in the same way with our own special character for the time being.

[gayanper]

I'm fine with making this a mostly UI-specific change to vscode-java. After all, the only thing we should do on the language server side is augment the DocumentSymbolParams to have an optional boolean includeInheritted. Either that or just create a separate method in the protocol for our need.

You mean add a optional boolean parameter in both jdtls and vscode-java ends right ? This is ok if we can override the default quick-pick. But if not it might be better to have out own method with own quick-pick for this ?

Is it possible to override the document symbols quick-pick menu ?

Also, the closest thing I could fine was microsoft/vscode#86761 , which is something along the lines of "there should be more control over what symbols appear" . I noticed in there that in the editor symbol search quick-pick, if you type an : (after the @ that defines the search), it seems to categorize the symbols. Haven't seen this documented, but I wonder if we can override the search in the same way with our own special character for the time being.

I this the categorisation is done using the symbol type probably in UI. But i can check that.

[rgrunber]

I think we would need access to the following API :

• For registering quick access provider : https://github.com/microsoft/vscode/blob/5acd9508c913b1d0ce3243f056c3cb039bac6938/src/vs/workbench/contrib/search/browser/search.contribution.ts#L814-L820
• For implementation https://github.com/microsoft/vscode/blob/5acd9508c913b1d0ce3243f056c3cb039bac6938/src/vs/workbench/contrib/search/browser/symbolsQuickAccess.ts

This doesn't appear to be exposed currently though :\

[gayanper]

Yes thats what i found as well. So may be this could be presented in the reference-view which is used for type hierarchy and call hierarchy as well ?

The reason i thought like that is, from vscode design language it seems document symbol is just to view the symbols in the current document, a quick access to outline. So showing symbols in the super classes seems to be out of scope of this design language.

So may be looking at the class hierarchy with its symbols should be different feature and since its important for java (at least since most of the java IDEs has it) we could implement is as a view.

Its like super type hierarchy with symbols kind of a view.

WDYT @rgrunber ?

[rgrunber]

This might be a preference, but I have always found ctr + o + type immediately in the search filter + <Enter> to be faster/preferrable to using the outline view and clicking on the symbol. Maybe because I never liked the amount of space the outline view takes from the editor. With that said, you're right, that the outline view should also be changed, so maybe we can start with that for now.

Also, I think those developing language servers that have a notation of "includes" directives would run into the same issue. They'd want to display some symbols that are in a separate document as being part of the current one. So that's what makes me think that the "documentSymbols" concept is going to have to evolve eventually.

[gayanper]

This might be a preference, but I have always found ctr + o + type immediately in the search filter + <Enter> to be faster/preferrable to using the outline view and clicking on the symbol. Maybe because I never liked the amount of space the outline view takes from the editor. With that said, you're right, that the outline view should also be changed, so maybe we can start with that for now.

Not sure if you misunderstood me in my previous comment. I think for vscode outline also we cannot distinguish if the documentSymbol call is from outline or quick access popup right ? The outline will ask the symbol information hierarchically and we can use that as a hint. I was suggesting to present this in the reference view which is added from vscode-java. But did you had something else in mind ?

Also, I think those developing language servers that have a notation of "includes" directives would run into the same issue. They'd want to display some symbols that are in a separate document as being part of the current one. So that's what makes me think that the "documentSymbols" concept is going to have to evolve eventually.

Yes we can raise a improvement for LSP project.