Outline view

[gantsevdenis]

I went through documentation, and through features requests, but I couldn't find an "Outline" view like in VSCode for ex.:

It's quite difficult to navigate unknown code-base otherwise (in my opinion)

[kirawi]

I think this might be the LSP request to get a list of all the symbols: https://microsoft.github.io/language-server-protocol/specification#textDocument_documentSymbol

[joegm]

FWIW there is a symbol picker with space-s but I guess you're looking for something more advanced?

[sudormrfbin]

LSP supports hierarchical symbols, but helix currently flattens then into a list and shows them with space+s. We could reuse the tree view that will soon be merged with the file tree (#2377) to display the symbol information in a tree interface.

Another option is to use tree sitter tags instead of LSP (not sure if it can report hierarchical information).

[lukasjuhrich]

It may be worth noting that #2377 is closed and its successor #5768 is stalled and from the looks of it won't be merged.

Perhaps the question of a hierarchical symbol picker can be tackled separately instead of waiting for a broad change like a tree file picker? It seemed to me that the more broad question of „let's add a file picker“ has been received rather skeptically; perhaps people would be more willing to allow for this specific change when introduced on its own.

[psnelgrove-r7]

Found this issue while thinking about my workflow in large python projects in Neovim. Python LSP choices leave something to be desired when it comes to performance. But I found an alternative that I often find more useful and certainly more performant. That is to pull the outline directly from tree-sitter.

The best plugin I found for this was aerial.nvim. In my option, Aerial does too many things with it's stateful outline buffer. Things like collapse/expand sections and code folding. That's what you'll see in the readme demo video.

However, what's most relevant to my comment is the document symbol picker. It's very similar to the Helix symbol picker with the candidates to the left and preview to the right. The two subtle but very nice UX improvement here are the (optionally rended if available) NerdFont and the actual tree-sitter node content next to the symbol for quick context.

I think it would be interesting if space-s could support the two different backends since I think the UX can be identical.

To summarize, I think the main value propositions are:

1. Falling back to tree-sitter means that the default editor capabilities are there even if the LSP is not installed or configured.
2. A more performant per-file symbol picker for very large files.
3. More context on the line for each symbol pulled from the tree-sitter node (stating my ignorance here if the LSP response also gives this context and the picker just doesn't render it for simplicity).

[kirawi]

See #1252 for that

[ClassAteam]

Um... Is this issue still relevant? It is for me.