Nested symbols hierarchy #121
Comments
|
The problem with not taking the range into consideration is that names are not unique. Without it results are often ambiguous. |
|
But what about taking order into account? Symbols can be listed in the declaration order (sort by location start), then children always follow the parent, it's safe even if there will be another parent with the same name later. Apart from that, I think LSP specification should be improved to make it easier: adding |
|
To clarify my first paragraph:
|
|
OK, I see that it won't work well on this example: Both |
|
Yeah if you check the history for the OutlineViewAdapter you can see the various attempts at handling this up to the point we have today (which works well with C#, Java, TypeScript) Presumably the problem you're seeing is with ide-python? The spec doesn't explain why they don't want people producing a tree structure - it is incredibly useful and I suspect like the rest of the LSP spec it's entirely influenced by VSCode - which in this case did not have an outline/tree view at the time) I really want to keep the existing behavior but if we can fall back to something else if some information is missing we can do that. Alternatively an ide package can implement their own OutlineViewAdapter although I suspect given the limited token information it just won't ever look good. |
|
Check out microsoft/language-server-protocol#132 for some related discussions. Anyway this is firmly in atom-languageclient + LSP territory so I'm closing it here :) |
Nope, I noticed it working on the Scala language server (scalameta/metals#34), but it's still in progress, so I think will work it out with nested ranges. And yes, in the linked issue there is a direct reply in microsoft/language-server-protocol#132 (comment):
So it's a won't-fix from the LSP side, or at least not in this type of request. Also some general comments from another thread:
Which makes sense.. |
|
The reality is in fact that most LSP's are returning information that can be used to infer a hierarchy and it looks great when it does. It doesn't need a full AST to do so as we're only really rendering important details. Let me know if you need any help getting the Scala ranges working. |
|
@damieng I agree. There are some notions common for all languages, like fully-qualified names or explicit information about nesting. I believe that only simplicity based on generalization and abstraction is helpful and liberating while simplicity based on the target usage is only limiting. And thanks for support 👍 I think I got it right: scalameta/metals#34 (comment) 😉 |
Description
Outline view symbols hierarchy doesn't get nested based on the
containerNameproperty of the symbol, but requires that location ranges are nested.Citing the LSP spec about
locationfield ofSymbolInformationobject:(my emphasis)
The point is that the outline tree structure should be based on the "parent" relation: i.e.
containerNamematching thenameof the parent symbol.Current Behavior
Following example response contains a chain of nested symbols located each on a separate line:
An example JSON body of the response I sent
[ { "name": "File", "kind": 1, "location": { "uri": "...", "range": { "start": { "line": 1, "character": 1 }, "end": { "line": 1, "character": 2 } } } }, { "name": "Module", "kind": 2, "containerName": "File", "location": { "uri": "...", "range": { "start": { "line": 2, "character": 1 }, "end": { "line": 2, "character": 2 } } } }, { "name": "Namespace", "kind": 3, "containerName": "Module", "location": { "uri": "...", "range": { "start": { "line": 3, "character": 1 }, "end": { "line": 3, "character": 2 } } } }, { "name": "Package", "kind": 4, "containerName": "Namespace", "location": { "uri": "...", "range": { "start": { "line": 4, "character": 1 }, "end": { "line": 4, "character": 2 } } } }, { "name": "Class", "kind": 5, "containerName": "Package", "location": { "uri": "...", "range": { "start": { "line": 5, "character": 1 }, "end": { "line": 5, "character": 2 } } } }, { "name": "Method", "kind": 6, "containerName": "Class", "location": { "uri": "...", "range": { "start": { "line": 6, "character": 1 }, "end": { "line": 6, "character": 2 } } } } ]Here's how it looks in the outline view:
Expected Behavior
This result was achieved with the following response body
[ { "name": "File", "kind": 1, "location": { "uri": "...", "range": { "start": { "line": 1, "character": 1 }, "end": { "line": 35, "character": 1 } } } }, { "name": "Module", "kind": 2, "containerName": "File", "location": { "uri": "...", "range": { "start": { "line": 2, "character": 1 }, "end": { "line": 34, "character": 1 } } } }, { "name": "Namespace", "kind": 3, "containerName": "Module", "location": { "uri": "...", "range": { "start": { "line": 3, "character": 1 }, "end": { "line": 33, "character": 1 } } } }, { "name": "Package", "kind": 4, "containerName": "Namespace", "location": { "uri": "...", "range": { "start": { "line": 4, "character": 1 }, "end": { "line": 32, "character": 1 } } } }, { "name": "Class", "kind": 5, "containerName": "Package", "location": { "uri": "...", "range": { "start": { "line": 5, "character": 1 }, "end": { "line": 31, "character": 1 } } } }, { "name": "Method", "kind": 6, "containerName": "Class", "location": { "uri": "...", "range": { "start": { "line": 6, "character": 1 }, "end": { "line": 30, "character": 1 } } } } ]In this case ranges are nested.
Versions
Additional Details
Installed packages (`apm ls --installed`)
The text was updated successfully, but these errors were encountered: