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

documentSymbol method (SymbolInformation) should return tree instead of flat list #327

Closed
Yanpas opened this issue Oct 30, 2017 · 12 comments
Labels
feature-request Request for new features or functionality

Comments

@Yanpas
Copy link

Yanpas commented Oct 30, 2017

Currently there is no protocol defined way to build a tree of symbols (e.g. method foo inside class Bar inside package buz). It results that there is no reliable way to build outline of symbols.

SymbolInformation contains location and containerName members.

location's range doesn't have to denote a node range in the sense of a abstract syntax tree

containerName can't be used to re-infer a hierarchy for the document symbols

There should be some parent member or something.

@patrys
Copy link

patrys commented Oct 30, 2017

Related discussion: #132

@dbaeumer
Copy link
Member

Also related to #136

@dbaeumer dbaeumer added the feature-request Request for new features or functionality label Nov 15, 2017
@dbaeumer dbaeumer added this to the Backlog milestone Nov 15, 2017
@Yanpas Yanpas changed the title SymbolInformation method should return tree instead of flat list documentSymbol method (SymbolInformation) should return tree instead of flat list Feb 26, 2018
@rcjsuen
Copy link
Contributor

rcjsuen commented May 17, 2018

A new hierarchical outline has been added in VS Code .

What does this mean for the LSP?

@dbaeumer
Copy link
Member

Either we have a second request or we add a second return type to the existing one. Something like Hierarchy<SymbolInformaiton>

@dbaeumer
Copy link
Member

dbaeumer commented Jul 6, 2018

@dbaeumer
Copy link
Member

dbaeumer commented Jul 6, 2018

Feedback appreciated.

@rcjsuen
Copy link
Contributor

rcjsuen commented Jul 6, 2018

@dbaeumer Thanks, Dirk. I took a quick look at your commit.

I wonder if the detail field should be optional instead? I guess it can also be an empty string? For a simple class declaration the name is simply going to be MyClass and there won't be any additional details, correct?

Also, the idea is that the response to a textDocument/documentSymbol will now be DocumentSymbol | SymbolInformation[] | null, correct?

@dbaeumer
Copy link
Member

@rcjsuen Yes, the idea is that the reponse returns

DocumentSymbol[] | SymbolInformation[] | null

Note that it is DocumentSymbol[]. Reason being is that I am not a fan of an artificial root node for the file which in some languages will not represent a symbol.

@dbaeumer
Copy link
Member

Making the details optional makes sense to me as well. Will make the change since an empty string is not better.

@kittaakos
Copy link

From the 3.10.0 changelog:

Add support for hierarchical document symbols as a valid reponse to a textDocument/documentSymbol request.

Isn't it already supported by the protocol?

(Sorry for the noise, if no.)

@Yanpas
Copy link
Author

Yanpas commented Sep 5, 2018

Yes, seems to be already implemented with new outline feature in vs code

@Yanpas Yanpas closed this as completed Sep 5, 2018
@dbaeumer
Copy link
Member

dbaeumer commented Sep 7, 2018

@kittaakos thanks for pointing this out.

@vscodebot vscodebot bot locked and limited conversation to collaborators Oct 20, 2018
@dbaeumer dbaeumer removed this from the Backlog milestone Nov 2, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature-request Request for new features or functionality
Projects
None yet
Development

No branches or pull requests

5 participants