Hierarchical Outline View using clangd's DocumentSymbol

[mvohla]

tl;dr: Interest in updated Outline view with symbol hierarchy and details?

Hi,

I'm a big fan of Outline views for code navigation. The thing is, for my taste the existing Outline plugin is rather on the basic side (no sorting, no hierarchy, no details ...).
CodeLite has already a very nice LSP client implementation and I admire all the work that has gone into it. For my personal use I wrote a little parser to create a symbol hierarchy and changed the Outline panel to display it in a sortable tree view.
This works fine for all my stuff and boosts my efficiency, but it's not suitable for general usage (the created hierarchy is mostly based on line and character ranges, which the clangd spec explicitely discourages). I also have no idea how this would behave in other languages.

Most of this can be solved by requesting DocumentSymbol from clangd instead of SymbolList and representing this hierarchy as a sortable tree. Obtaining the DocumentSymblos is mostly a matter of setting the richt client capabilities.

But before I go about implementing it, I wanted to get a few opinions from the CodeLite team:

• Is anybody already working on improving the (clangd-)Outline?
• Is there any reason, besides the required time / other priorities / other fancy features, that the Outline has been kept as a simple list? At least the corresponding class is there already.
• Is there any interest at all in having an updated Outline plugin? If yes, I'll gladly implement and contribute it.
• Because I'm lazy and have only been using CodeLite for a couple of weeks and exclusively for C++: Is the same Outline plugin used for other languages, or exclusively for C++/clangd?

Thanks for reading!

Cheers, Mike

[eranif]

Is anybody already working on improving the (clangd-)Outline?

No

Is there any reason, besides the required time / other priorities / other fancy features, that the Outline has been kept as a simple list? At least the corresponding class is there already.

No

Is there any interest at all in having an updated Outline plugin? If yes, I'll gladly implement and contribute it.

I am always in favor of improving the current implementation

Because I'm lazy and have only been using CodeLite for a couple of weeks and exclusively for C++: Is the same Outline plugin used for other languages, or exclusively for C++/clangd?

Yes. The plugin is generic to all LSPs (I have been using it with Rust & Python as well as C++).

Most of this can be solved by requesting DocumentSymbol from clangd instead of SymbolList and representing this hierarchy as a sortable tree

CodeLite already requests DocumentSymbol

codelite/CodeLite/LSP/DocumentSymbolsRequest.cpp

Line 33 in 81c22d5

SetMethod("textDocument/documentSymbol");

[mvohla]

Hi, thanks for your answer!

I should have a prototype working at the end of the weekend.

CodeLite already requests DocumentSymbol
True, but the response depends on the textDocumentCapabilities sent during initialization.

Hierarchical Document Symbols are intruduced in LSP 3.10.0 (7/23/2018). Is there any need to support older Language Servers that only support SymbolInformation?

[eranif]

Hierarchical Document Symbols are intruduced in LSP 3.10.0 (7/23/2018). Is there any need to support older Language Servers that only support SymbolInformation?

This depends on the major LSPs, the ones I consider major and uses them are:

• rust-analyzer
• clangd
• python-lsp-server

[mvohla]

The basic stuff is working (Hierarchical tree in outline dialog and outline view). Sorting functions are still tbd, as well as some optical polishing. Also I feel an indicator is needed to show feedback that the outline is waiting for a response from LS, since it can take a couple of seconds with large files.

I kept the original method as a fallback, in case the LS does not support hirarchical symbols.

Once I finished the details and did some more testing with other LS than clangd, I'll create a PR. Meanwhile the code is here: https://github.com/mvohla/codelite/tree/outline

[eranif]

This looks very nice! One small suggestion:

An option to start it in a collapsed mode would be great (this option should persist, you can use clConfig::Get().Read(..) & clConfig::Get().Write(..) for this purpose.

[mvohla]

Thanks for the suggestion :)

I added these options (persistance tbd) and cleaned everything up. Will be moving on to testing with LS other than clangd now, as well as building/testing under Windows (MacOS not possible for me).

I'd like to add some open licensed SVG icons, e.g. for tree collapsing/expanding.
Is there a preferred source for that? Otherwise I'll use e.g. svgrepo.com and iconmonstr.com.
Is there a place to add attribution to those sites? I'm thinking of adding an "Attribution" button in the about dialog. Or just put their license file in the resource folder?

Cheers, Mike

[eranif]

Looks awesome, looking forward for the PR.

[eranif]

As long as the SVG is free to use - get it from ever you want.

[mvohla]

Little update:

1. Usage-Tests with rust-analyizer and pylsp are ok. Since pylsp/python-lsp-server still doesn't return a hierachy, only a flat list (nothing has changed since your comment on the project page a couple of years ago), I added the option to parse the list into a tree based on Ranges.
2. Added svg icons, mostly self-drawn
3. Added fine-grained initialisazion options (what to expand/collapse when symbols are loaded)

Only thing left to do is building/testing on win32.

[eranif]

Great. However, Are the current SVG not enough? i.e. we already have a SVGs for function, class etc.
They are used in the code completion box.

For example:
https://github.com/eranif/codelite/blob/master/svgs/light-theme/function_public.svg

Full list:
https://github.com/eranif/codelite/blob/master/Plugin/bitmap_loader.cpp#L231

[eranif]

Other than that, feel free to post this as a PR so we can start the review iteration :)

[mvohla]

As for the symbols, I think it comes down to personal taste. For me the pure color coding of classes/structs/functions was not quite distinctive enough. We'd also have to at least add svgs for constructors and modules, and maybe make namespace and enum icon distinguishable.
It is, of course, possible to use the existing svgs (plus the missing ones), and let it be up to the user to exchange them after installation according to taste. Although for that it's also nice to have them grouped with the symbol- prefix.

I'll make the pull request later, after resolving some merge conflicts. The style of the symbols can be changed then.

[eranif]

The more important thing is that the UI has to be consistent. If we already have symbols - they should be the same everywhere:

• In the code completion box
• Navigation drop down button
• The outline view.