I understand why you are requesting this (because of the type hierarchy request) but IMO this is not the right way to go. DocumentSymbols are as the name implies scoped to a document and we shouldn't start changing this. I would rather opt to have a new type TypeHierarchyItem. This ensures we can evolve them independently. In addition we can make these items lazy to better support large type hierarchies.

Any objection to close this ?

because of the type hierarchy request

Yes :)

I would rather opt to have a new type TypeHierarchyItem.
This ensures we can evolve them independently.

This was the initial idea.

Any objection to close this ?

I do not mind adopting the proposals. What's your take on that, @svenefftinge?

I would rather opt to have a new type TypeHierarchyItem.

IMO the name TypeHierarchyItem is not good since the class could be usefull for cases not related to type hierarchy. E. g. in Eclipse you could list the class symbols + inherited members.

IMO the name TypeHierarchyItem is not good since the class could be usefull for cases not related to type hierarchy. E. g. in Eclipse you could list the class symbols + inherited members.

It should be still possible with the TypeHierarchyItem.

Presumably, you are talking about the Ctrl/Cmd+o functionality in Eclipse. It is your outline: textDocument/documentSymbol.

If you want the inherited members (Ctrl/Cmd+o and Ctrl/Cmd+o again), you can get the supertypes of the current document: textDocument/superTypes, and execute textDocument/documentSymbol for each type. Finally, you merge the result on the client. Although, I did not check with JDT, I would assume, Eclipse does it in two steps too. @yyoncho, correct me if I've overlooked something.

If you want the inherited members (Ctrl/Cmd+o and Ctrl/Cmd+o again), you can get the supertypes of the current document: textDocument/superTypes, and execute textDocument/documentSymbol for each type. Finally, you merge the result on the client. Although, I did not check with JDT, I would assume, Eclipse does it in two steps too. @yyoncho, correct me if I've overlooked something.

Deciding on whether a symbol is inherited or overridden requires knowledge of language semantics, so I'd say this is something to be provided by the language server and not the client.

Given the various listed use cases I still think it would be reasonable to have an abstraction for 'a symbol in a document'. But I see @dbaeumer point about the documentSymbols name conflicting.

The LSP actually tries hard to stay way from this. All the types it declares are bound to a tool action and usually return UI data types. The documentSymbols request would have better be named documentOutline and returned OutlineItems.

For most servers that request doesn't return all symbols defined in a document (for example locals are usually not part of this).

I will close the issue. Please ping if someone disagrees.