nvim-neo-tree / neo-tree.nvim

Neovim plugin to manage the file system and other tree like structures.
MIT License
3.81k stars 222 forks source link

Feature request: browser workspace symbols as nodes in file tree #593

Open yingzhu146 opened 1 year ago

yingzhu146 commented 1 year ago

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.

20221106-174517

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:

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 commented 1 year ago

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 commented 1 year ago

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:

20221109-071714

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 :))