Refactor Picker as a table with multiple columns/filters

[the-mikedavis]

The Menu-like portion of the Picker is replaced with a table. Picker::new takes a set of Columns which each contain custom logic for rendering and optionally sorting and filtering an option. (Previously ui::menu::Item implemented that logic.) This allows filtering a picker by more than one value.

Here's a small example showing changes to the symbol picker (<space>s) and the buffer picker (<space>b):

Here I open up the symbol picker (<space>s) which has two columns: symbol kind (function, enum, module, class, etc.) and name. By default the search works on the primary column which is configured as the symbol name. I can also limit the search to just %kind:field though. The buffer picker can filter by buffer ID, modification/focus flags and path. The diagnostics pickers can filter by severity, code, message, and path (for the workspace-wide diagnostics picker).

The workspace symbol picker can filter separately by symbol name, filename, and symbol kind. The symbol name is no longer passed to the fuzzy matcher which fixes some minor issues when using language-server-specific query syntaxes (see #5714). This paves the way for dynamic global search but I have left that off of this PR as the change will be large on its own.

Closes #7040
Closes #5714
Closes #5446
Closes #5110
Closes #2452
Closes #3543

There are a few TODOs:

• Allow quoting in the picker's field syntax
• Figure out if this needs theming changes (adding a theme key for the primary column?)
• Improve width constraint calculations so large columns share the space better

[pascalkuthe]

This is awesome! I wanted to implement this sometime too but never got around to it. I think this has a ton of potential 👍

I dont have time to review right now but it's great to see that you started on this

[the-mikedavis]

Separate prompts for each field feels a little clunky. Instead I think we should have only one prompt, drop the "active column" concept, and use a lucene-like syntax for filtering by fields. For example the symbol picker could take some queries:

• func mysym: fuzzy-match by "func mysym" across all fields
• kind:func mysym: fuzzy-match by "func" in the "type" field and "mysym" in the remaining fields (symbol name)
• func name:mysym: fuzzy-match by "mysym" in the name field and "func" in the remaining fields (symbol kind)

(The ordering in these examples shouldn't matter.) Values with spaces could be wrapped in quotes, for example kind:"enum member". The matches would have an implicit AND relationship but we could support AND/OR as well if necessary.

Other examples:

• flags:+ in the buffer picker would filter down to modified files
• severity:error code:34 path:src/ my error message could be used in the diagnostics picker

[pascalkuthe]

I like the general idea of having a single field. The reason I suggested split columns before is that:

• Not all columns may fit on screen at once
• potential false positives (solved by the explicit kind: syntax but makes matching for multiple words in the same column (which I do quite a lot) without false positives quite awkward For example: file:syntax.rs file:helix-core file:src instead of syntax.rs helix-core src` on master.
• Most importantly: How does this work with dynamic pickers. Fuzzy matching across all columns doesn't work for regex queries
• one Small thing : is too common to require escaping we should use a less common char

My idea to resolve these is the following:

• %kind will treat all following words until the next word starting with % (or EOL) as queries for the kind column. While typing in such an area that column is called active
• It the last column name is unknown (or empty) all (non-dynamic} columns are active at once (like you said fuzzy match across everything)
• When there is not enough space to display all columns, priority is given to the active column
• Since dynamic columns always need to be manually activated we can prefill the picker when it opens to make that more convenient. For example for interactive global search, we prefill %query foo+bar % (typing immediately fuzzy matches all columns which would just be path in this case while keeping the qury from the prompt ). For the workspace picker, we just prefill %query and the user can start filtering immediately.

A distant future idea: we could create typable command versions of the pickers that accept a prefill as an argument. This would allow binding: open function picker to a key without adding a dedicated command.

It doesn't look as sleek as your variant but it should work quite well. What do you think?

[the-mikedavis]

For dynamic pickers, I have some local changes that allow disabling filtering/sorting on a column. That will resolve #5714 and allow entering regexes for the global search dyn picker. I also have a change locally that allows specifying an input register for global search to set an initial query.

For prefilling pickers, I think specifying a register would be a nice way to do it. I have some local changes building on #7277 that allow a sequence like "/<space>/ to open global search using the / register contents as the initial query. That could be done for other pickers as well.

I like the active column idea you describe for a priority in rendering. For matches with long lines the global search picker can get very cramped. I think there's room for improvement with truncating columns so that outlier long matches don't push the other columns out, and columns share the available space more evenly.

I'd like to start with a proof-of-concept using the : syntax but try it both ways. I think : might be sufficient: we may be able to make smart decisions while parsing to ignore :s not used in fields. And about the file:syntax.rs file:helix-core file:src example, I think that could be the behavior of file:"syntax.rs helix-core src".

[pascalkuthe]

For dynamic pickers, I have some local changes that allow disabling filtering/sorting on a column. That will resolve #5714 and allow entering regexes for the global search dyn picker. I also have a change locally that allows specifying an input register for global search to set an initial query.

For prefilling pickers, I think specifying a register would be a nice way to do it. I have some local changes building on #7277 that allow a sequence like "/<space>/ to open global search using the / register contents as the initial query. That could be done for other pickers as well.

I like the active column idea you describe for a priority in rendering. For matches with long lines the global search picker can get very cramped. I think there's room for improvement with truncating columns so that outlier long matches don't push the other columns out, and columns share the available space more evenly.

I'd like to start with a proof-of-concept using the : syntax but try it both ways. I think : might be sufficient: we may be able to make smart decisions while parsing to ignore :s not used in fields. And about the file:syntax.rs file:helix-core file:src example, I think that could be the behavior of file:"syntax.rs helix-core src".

What I mean about the dynamic picker is that when you enter a string without specifying a column it wouldn't work well to fuzzy match that across all column (I would iamgine that works by ocmbining all colums into a single string that is then fuzzyatched on so you can't also modify the query that way). I think for dynamic pickers you always have to specify the column. Hence the idea to have an easy syntax for specifying queries with spaces. I think something more convenient that quotes might be nice for that but we can always bikeshed that later.

Yeah for prototyping the syntax probably doesn't matter that much 👍 It should be easy to change/experiment with later. If we use column: we could indeed make that only active if such a column actually exists (removing the need for escape in most cases). That could.be a nice variant too.

Using a register for prefill is nice. That syntax looks neat

[the-mikedavis]

Ah yeah I see what you mean now. For the time being I have made the behavior different in dynamic pickers and regular pickers: in dynamic pickers, the "common" text (text without a field specified) automatically acts as the dynamic column's input any other fields need to be specified explicitly. It feels intuitive but I'm not sure I like having split behaviors.

[jhugs]

When you get a chance to rebase again I'd love to test this out

[the-mikedavis]

I rebased this on top of master with the nucleo changes. Kudos to @pascalkuthe: the column support in nucleo makes the changes to the fuzzy matching parts very clean! 🎉

I have reduced the scope of this PR a little so that dynamic global search is left for the future. global_search now includes the matched line's contents but isn't a DynamicPicker. That change can be done after this PR and I'd like to base it on #8021 so that we have better control over DynamicPicker's debounce behavior. (IME running this branch we want a longer debounce for global search.)

There are a few more changes I'd like to make to this branch but I think it's nearly ready for review.

[pascalkuthe]

Github doesn't let me link this properly (the ui is super broken) but this also addresses #3543

[matuusu]

Are there any plans to move this PR forward?

[the-mikedavis]

Yep, I keep this branch up to date locally and build on it for other changes (see #196 (comment)). I'm waiting on #8021 for some of the changes to global search but the table refactor could be done independently. I'll rebase this branch and clean up the commits when I get a chance.

There are two small changes this branch needs too:

• The table header needs to be accounted for when paging up/down in the results - currently we ignore the header so we're off by a few lines when switching pages
• @pascalkuthe mentioned a good idea that you should be able to use prefixes of column names and have that select the correct column, so you could say %p:syntax.rs instead of %path:syntax.rs for example

[ItsEthra]

@pascalkuthe mentioned a good idea that you should be able to use prefixes of column names and have that select the correct column, so you could say %p:syntax.rs instead of %path:syntax.rs for example

I have a branch that implements it, should I make a pr to this branch for that? I made it so if multiple columns match %prefix, then it selects the columns with the shortest name(because it would fit prefix the most) or the first column of all matches.

[the-mikedavis]

I will probably recreate this branch from scratch rather than deal with the conflicts. If you link your branch I will pick up the commit from it when I revisit this

[ItsEthra]

My branch is here, I also rebased it on master, there was just one conflict and it seems alright.

EDIT: Search results are dupped on that branch, ig conflicts were not easy after all. fixed

[the-mikedavis]

@pascalkuthe what do you think about using fuzzy matching for this instead? It would be more forgiving, so you could use %pth:syntax.rs for path for example. We could even highlight the parts of the column name that matched, like we do for the parts of the query that match items

[the-mikedavis]

We discussed this and fuzzy matching seems like overkill - the prefix is more straightforward. Highlighting the matching parts could also be done for prefix strings as well and would be simpler. (Could be a follow-up to #9647)

[the-mikedavis]

Closing in favor of #9647 which includes these commits