Feature request: browser workspace symbols as nodes in file tree

[yingzhu146]

Hi! Thanks for the great plugin.

When I'm exploring a new, large codebase I often like to get a picture of the key Classes/methods in each namespace.

LSP provides this, with the workspace/symbol request.

The feature request would be to add an additional level of nodes to files, which can be browsed identically to directories and files, with symbols.

e.g.

in this arbitrary tree, when pressing <CR> on init.lua it would open an additonal level of the hierarchy and have all symbols. (e.g. M.setup, M.do_x_y_z would be entries).

When pressing <CR> on the symbol, I would then expect to open the file and jump right to the correct symbol

Even cooler, would be amazing to highlight the surrounding symbol of the current cursor location in the tree view.

Why this would be a good idea:

• effectively brings a more powerful version of symbols-outline.nvim functionality right into neo-tree (symbols-outline uses textDocument/documentSymbol which only provides the current document symbol, unfortunately
• allows you to really quickly explore/recall core objects/symbols of large code bases and would help a lot getting more familiar with them
• gives you a "table of contents" for free
• allows opening files in more specific locations vs just top of the files more quickly
• allows always knowing the full current context (project->directory->file->symbol) which can be extremely helpful
• it's cheap because workspace/symbols returns all project symbols so only has to be called, parsed once and upon save in background
• getting the info is actually really easy - here is the code snipped to get all symbols for the current workspace - I would make a PR but am not familiar with the neo-tree code base enough yet to parse and add it to the tree

vim.lsp.buf_request_all(0, "workspace/symbol", { query = "" }, function(result) print(vim.inspect(result)) end)

This functionality is actually already in telescope - see Telescope lsp_dynamic_workspace_symbols - which could help giving and example of implementation. Additionally, symbols-outline.nvim contains much of the symbol parsing code necessary already.

Let me know what you think!

[cseickel]

I did plan on doing this (someday) as a separate source which would be for the current file only: #14

I know that other editors will include it within the file browser but I'm not sure if I like that. As a user, it seems a little overwhelming to have so many levels of information. As an engineer maintaining the code, It's so much cleaner to have smaller and separate modules that each do one thing.

I'm not saying I won't do it, but I would at least want to do the separate source first and then think about integrating it with the filesystem source next.

[yingzhu146]

Thanks a lot - definitely understand the maintainability aspect. Let me elaborate on why I think having them joined and workspace wide would be required to solve my usecase:

• Having them separate wouldn't exactly solve my use case since I'd be more looking for something that shows full path including symbol, similar to e.g. how lspsaga implements the winbar component

• There is many solutions that show textDocument/documentSymbol (symbols-outline, lspsaga, mini.nvim, ...) so only showing for the current symbol wouldn't really add any value for my workflow.

Overwhelming information doesn't need to be the case since nodes would be collapsed by default - it's not different from just having a nested file structure - I e.g. often have pwd in ~ with neotree, and have 1000's of files with 5+ levels of hierarchy without issue, which is much more than what this would entail.

Thanks a lot for considering this - realize it's a big feature request and might be very niche for my workflow (there is a few likes on my equivalent request on symbols-outline so it seems at least a few others would like that too :))