Add more context to the symbol picker #2452

mdelaney · 2022-05-10T06:16:41Z

The symbol picker functionality is really useful; however, it can be annoying when you want to do something like only see the function symbols, or maybe only struct or enum kinds. It'd also be convenient to be able to filter by the containing symbol name.

This adds the symbol kind along with its direct parent symbol. So:

mod foo {
    fn bar() {}
}

will show symbols like

module    : foo
function  : foo → bar

This lets you quickly filter by the symbol kind, containing symbol or
symbol name.

Here is how this looks before (top) and after (bottom):

The nice thing about this is that you can search by the symbol type (like function) to more quickly narrow in on what you want.

By showing the containing symbol (if it exists) it becomes easy to search only symbols in the test module as well.

This also addresses a TODO and a bit of minor formatting cleanup.

This adds the symbol kind along with its direct parent symbol. So: ```rust mod foo { fn bar() {} } ``` will show symbols like ``` module : foo function : foo → bar ``` This lets you quickly filter by the symbol kind, containing symbol or symbol name.

CptPotato · 2022-05-13T06:55:36Z

Some personal feedback, take it with a grain of salt:

The display of namespaces/modules with an arrow looked a little odd at first glance. I like that the module is shown, though.
Does it include all modules for deeply nested projects or only the last one?

Would it be possible to have the item type (function/enum/etc.) aligned to the right or does this break searching for fun xyz?
I'm seeing parallels to the completion popup which looks different from this PR's current formatting (right aligned, no dividing char like :). I'm not sure if it's worth it, but having more consistency in the UI might pay off. (there's also #1905 which adds colors to the completion popup).

mdelaney · 2022-05-13T15:32:58Z

Hi @CptPotato, thanks for the feedback!

The display of namespaces/modules with an arrow looked a little odd at first glance

Yea I played around with some other possibilities like => or simply :. Is there any convention already established elsewhere for this? Very much willing to change this, biggest goal was to minimize the number of characters to keep as much room as possible for the symbols.

Does it include all modules for deeply nested projects or only the last one?

Unfortunately the symbol only contains the direct parent and didn't find a good way to get the rest of the hierarchy. I played around with building up a hash map but ran into some problems when there are symbols with the same name. It feels like this is something that should be solvable with tree-sitter (though admittedly I haven't played with that). If you have any specific ideas on how to get this I'm happy to play with this further (otherwise can very much put a TODO here).

Would it be possible to have the item type (function/enum/etc.) aligned to the right or does this break searching for fun xyz?

Could be. I'll play around with this in the next day or so. I agree it'd be kinda nice to have it right aligned if it doesn't make filtering more difficult.

CptPotato · 2022-05-13T18:41:17Z

Thanks for elaborating!

I personally don't have a strong preference for how to separate the namespace from the symbol name. Different languages have different conventions here (like :: in Rust and C++ vs . in C#). I also thought about using / like it's used in paths, but users might mistake it for an actual file system path which isn't necessarily the case depending on the language.
Anyway, I agree that shorter is probably better to save on line width.

I also don't think it's a big issue that only the parent namespace is shown in the list for now. If a project has a very deep structure, it might clutter up the window and make it harder to see the actual symbol name on smaller screen sizes.

mdelaney · 2022-05-13T19:26:31Z

The problem with only showing the immediately containing symbol is pretty well shown in helix-core/src/movement.rs in the test module. Consider the following enum Axis definitions.

first
second

this would show up something like:

enum      : vertical_moves_jumping_column → Axis
enum mem  : Axis → H
enum mem  : Axis → V
enum      : multibyte_character_wide_column_jumps → Axis
enum mem  : Axis → H
enum mem  : Axis → V

Definitely an improvement over the current output but it'd be much nicer to have the full nested structure (albeit truncating long names to make the length reasonable). (FWIW this is the exact example that broke my initial implementation 😛 )

All that to say, this still feels like a problem that should be solved (though maybe outside the scope of this PR). I suspect that this would be more problematic in some languages than others.

mdelaney · 2022-05-14T04:37:03Z

@CptPotato - Ok, so after digging in a bit more....

Would it be possible to have the item type (function/enum/etc.) aligned to the right or does this break searching for fun xyz?

This isn't possible without significantly reworking how the picker is implemented. In the PR you linked the right alignment is done by using two Cells in the table widget.

That said, right aligning also makes filtering by symbol kind pretty awkward as the filtering is from left to right, so you'd have to do something like foo function but that eliminates the ability to first filter by the symbol kind and then by name.

I think there'd be a lot of value to reworking the picker to support style information to use color to differentiate pieces of information in the picker. Even before this PR, the workspace symbol picker has the symbol and file path, it'd be really great to have them styled differently to make it easy for the eye to parse the different pieces of information. (if there is general agreement on that direction I'd be happy to spend some time on it at some point)

I added a TODO for adding ancestor symbols.

For the separating symbol, my view is that a simple → is probably the simplest least ambiguous option given that the symbol to the left literally contains the symbol to the right. This stays away from language specific symbols and is only a single char wide.

Any thoughts?

CptPotato · 2022-05-14T09:56:40Z

I think reworking the picker to make alignment, coloring or searching work better is out of scope for this PR. It might be worth revisiting in the future, but for now I think having the item types added to the symbol picker is already a nice addition. 👍

pickfire · 2022-05-14T13:30:47Z