Add hierarchical DocumentSymbol support (LSP 3.10)

[zen010101]

Summary

Implement dual-mode DocumentSymbol provider supporting both LSP 2.x flat mode and LSP 3.x hierarchical mode, enabling better IDE integration and symbol navigation.

Changes

• Add TSymbolMode enum and TSymbolBuilder class for dual-mode symbol building
• Detect client hierarchicalDocumentSymbolSupport capability during initialization
• Build hierarchical structure with parent-child relationships when supported
• Return DocumentSymbol (with range/children) or SymbolInformation (with location/containerName) based on client capability

Benefits

• Better IDE integration: Outline view shows proper nesting in VS Code
• Hierarchical navigation: Enables symbol search with Class/Method paths (e.g., TUser/GetFullName)
• Backward compatible: Clients not supporting hierarchical mode still work with flat SymbolInformation
• LSP 3.10+ compliant: Follows the official LSP specification for DocumentSymbol

Testing

Tested and verified with:

• ✅ VS Code extension - Hierarchical mode working, Outline view shows proper nesting
• ✅ Serena MCP - Hierarchical mode with depth parameter working correctly

Screenshots

VS Code Outline view showing hierarchical structure:

• Classes can be expanded/collapsed
• Methods are nested under their parent classes with proper indentation
• Clear tree structure instead of flat list

References

• LSP 3.10 DocumentSymbol specification
• Backward compatible with LSP 2.x SymbolInformation

---

This is the first PR in a series. Future work will add Property and Field symbol extraction.

[zen010101]

[zen010101]

[zen010101]

Merry Christmas to everyone! 🎄🎁

[genericptr]

I see two problems here:

1. The symbols in the toolbar below the tabs in VSCode are in some methods showing as ... where they used to show the full path. Can you test that again? I think there was a regression.
2. Nested functions are not appearing in the outline now which is another regression.

btw, @zen010101 do you know how much this interacts with #98? I didn't get a chance to review this and I see multiple problems with it which I think you're building on with DocumentSymbol changes.

Here's at least two places where the structure is wrong and are missing their parents. I seem to be remember SublimeText showed the hierarchy as Interface > TClass > Method > NestedFunc etc... if it was setup properly. My old code before that PR used to use dot notation like Interface.TClass.Method.NestedFunc which I preferred for SublimeText and I see you have a "flat" option now. Could we bring back the dot notation for that setting?

Hmmm I just tested this in VSCode and it looks much better here so maybe that PR is working better than I thought but I still see regression in your code. It's pretty clear then we need a flat version for editors that don't support the hierarchy as well. Remember the LSP was made by Microsoft so they custom built VSCode around it and not all editors are willing to have the same UI.

[genericptr]

one last comment, the outline already looks correct to me in VSCode so what really changed here? Why do we need these changes at all?

[zen010101]

About PR #98

PR #98 attempted to add hierarchical display in flat mode by hardcoding interface/implementation string constants. This approach is problematic because:

• Flat mode (SymbolInformation) shouldn't have hierarchy - it's designed for clients that don't support nesting
• The implementation mixed concepts between flat and hierarchical modes
• It didn't properly solve the breadcrumb navigation issue

My PR takes a different approach: keeping flat mode unchanged while implementing proper hierarchy only in hierarchical mode (DocumentSymbol with children).

About SublimeText

Regarding SublimeText compatibility: I don't currently have SublimeText installed. I'll download and test it in the coming days to ensure flat mode works correctly with the dot notation format you mentioned.

Why hierarchical mode is needed

1. Modern IDE expectations: LSP 3.10 introduced hierarchical DocumentSymbol specifically because flat SymbolInformation couldn't meet modern IDE navigation needs. Most LSP clients now prefer hierarchical mode when available.

2. MCP/AI agent integration: Tools like Serena MCP rely on hierarchical symbol trees for operations such as find_symbol with name paths like TClass/Method, and depth=1,2 to retrieve symbol descendants. These capabilities are impossible with flat mode's simple string-based containerName.

Flat mode still works for editors like SublimeText that only support flat lists. This PR keeps flat mode unchanged while adding proper hierarchical support for modern IDEs and AI-powered tools.