add initial support for type hierarchy

[prabirshrestha]

This PR embed's @m-pilia tree view plugin https://github.com/m-pilia/vim-yggdrasil

While the spec is still in progress clang supports it already in their releases though it could break in the future. This implements basic call hierarchy support which is useful specially for object oriented languages such as c++/java.

[github-actions]

[vint] _{reported by reviewdog 🐶}
Unused variable: object (see :help E738)

[clason]

Neat! Can this also be used for documentSymbol if the server supports hierarchical symbols?

[prabirshrestha]

DocumentSymbol is also supported if the server doesn’t comply with the spec currently but it uses quickfix. #631

Ideally I do want to have official support for hierarchy using this tree. Still playing around with the tree library before I can make it default to others.

For type hierarchy it is safe because only few servers support it currently.

[clason]

I know that documentSymbol is supported and used the quickfix list; it's one of functions I use often ;) The server I use (texlab) does comply with the spec but sends a flat list if the server doesn't announce hierarchical symbol capability in ClientCapabilities. I may have confused documentSymbol and symbolInformation in my comment, though (wouldn't be the first time).

What I was asking (or, rather, slyly requesting) is whether the tree hierarchy can also be used for LspDocumentSymbol (and possibly LspWorkspaceSymbol, if that doesn't conflict with the filtering (it probably does)).

[prabirshrestha]

Tree hierarchy can be used for LspDocumentSymbol symbol and LspWorkspaceSymbol. This will most likely take a bit more time.

My thought was to have something like :LspDocumentSymbol -ui=tree where ui can be quickfix, loclist, tree and search that ships by default. This would allows other to hook in ctrlp/fzf.

I'm curious what do you usually use hierarchy for? Is it to visualize the hierarchy or just to make it easy to navigate. I personally want search instead of hierarchy since I never use hierarchy.

I might embed quickpick.vim once I lock down the apis since it has on_change and streaming api support which is required to support LspWorkspaceSymbol. I want LspWorkspaceSymbol -ui=search to look something like this.

Currently working on these fundamentals such as refactoring, testing callbag.vim so adding these features becomes very easy.

[clason]

Tree hierarchy can be used for LspDocumentSymbol symbol and LspWorkspaceSymbol. This will most likely take a bit more time.

Sure, no hurry! I just didn't want to forget.

I'm curious what do you usually use hierarchy for? Is it to visualize the hierarchy or just to make it easy to navigate. I personally want search instead of hierarchy since I never use hierarchy.

It's a bit hard to illustrate with a screenshot at the moment, but mostly for visualization. If you're not familiar with LaTeX, you can think of an HTML source, where the different tags have symbols -- so you'd have, e.g., a column in a row in a table in a div, and the hierarchy helps seeing at glance which columns belong to a row and which rows belong to a table when navigating.

My thought was to have something like :LspDocumentSymbol -ui=tree where ui can be quickfix, loclist, tree and search that ships by default. This would allows other to hook in ctrlp/fzf.

Yes, that sounds like a good idea. Personally, I'm not 100% certain about embedding stuff (seems to go a bit against the vim way -- but that should be treated like the pirate's code, really, and not preclude useful extensions).

My thought was to have something like :LspDocumentSymbol -ui=tree where ui can be quickfix, loclist, tree and search that ships by default. This would allows other to hook in ctrlp/fzf.

Speaking of which, what are your thoughts on the neovim's Great Lua Renaissance? Vim-lsp is still far ahead of the built-in LSP client, but it might make sense to refactor the neovim backend to leverage the new (Lua) API, both for LSP communication and for popups (once they have stabilized, of course -- this is one reason I've put my PR in hibernation)?

[prabirshrestha]

If using for outlining it makes sense.

Neovim doesn't work well in windows which is my primary machine at work so I can't depend on it. I love that neovim added lua as default, something I have been pushing for Vim to have too. https://groups.google.com/forum/#!searchin/vim_dev/vim$209%7Csort:date/vim_dev/__gARXMigYE/5v7dqcHfAwAJ, vim/vim#2115 and vim/vim#5198.
One of my problem with Lua is that it is not a static language and when the code base is big it gets very difficult to refactor/move or add features.

Currently my goal with vim-lsp is to have feature parity with both vim and neovim. In the future we might optimize for one. this is why we have lsp>ui>vim> folder.

Asyncomplete.vim is another one which is so small that I can completely write it in lua along side vimscript in the same plugin and was designed with that mindset. I'm still trying to convince Bram to have either wasm or lua so I can standardize the api.

async.vim is another place where one can easily swap the internal implementation.

lsp#client is the another one that can be completely swapped as long as it exposes the exact same apis.

To me all these are currently not a bottlneck but rather things like diff. So those are the ones that have higher priority then lua for other things that doesn't have perf issue.

Until vim doesn't have lua by default there are no plans for lua.

I just hope both vim and neovim supports wasm as this would solve two main issues I have with vimscript:

1. I can write in any static language
2. I can use threads to do heavy stuff.

Also wasm needs to be embedded and not installed as foreign interface like how vim does lua and python now. It is a mess to tell users to install the right version.

[prabirshrestha]

this is now merged. Seems like we need to start refactoring ui/vim.vim into smaller file.