Consider supporting SymbolInformation

[jason0x43]

A frequently reported issue, which I've run into myself, is the "x does not support documentSymbols" error popping up every time an editor is opened (#2, #5, #7, #15, #22, #36). The standard recommendation is to not attach navic to problematic servers. While this is reasonable in some cases, there are a number of servers that navic would be useful with, like htmlls or cssls, that still use the SymbolInformation interface.

Showing an error every time a new file is opened is informative, but not very ergonomic. Not attaching navic, or silencing errors, means that I won't be able to easily tell when the language servers have updated to using documentSymbol.

Looking at navic's parsing code and the LSP spec, the key difference that navic cares about is that SymbolInformation puts the location on location.range, whereas DocumentSymbol has a top-level range. The other properties used by navic appear to be the same. Given that the SymbolInformation API is still in use by a number of existing servers, and that it's deprecated and therefore shouldn't change, would it be worthwhile to support it? In my (very limited) testing, that might be as simple as pulling the range from the proper location.

[SmiteshP]

In my (very limited) testing, that might be as simple as pulling the range from the proper location.

Its not as easy as just using location.range instead of range. DocumentSymbol format arranges the nodes in a form of tree. Each node has a children field which makes it easy to traverse the tree and extract context easily and quickly. Whereas SymbolInformation is a flat list of all nodes with no information about node hierarchy.

here are a number of servers that navic would be useful with, like htmlls or cssls, that still use the SymbolInformation interface

I have tried looking at VScode's code to try to understand how does it work with htmlls. But due to my very limited knowledge of javascript, I am still clueless about it 😆 If anyone has any good ideas about how to work with SymbolInformation, please do share with me.

[jason0x43]

I see what you mean. If I had just read a little bit further in the source...

A hierarchy can be heuristically constructed by looking at overlapping symbol ranges; this appears to be what the VSCode outline view did when it was initially added.

The spec points out that symbol ranges can't reliably be used to reconstruct hierarchy, so I can see not wanting to support that because it may lead to a sub-optimal user experience in some cases, but it may still be worth considering.