enhance main quick pick items filtering logic

[taras-yemets]

Next iteration on #631
Follow-up on #798
Design

1. If input starts with a known command, only the matching item appears in the items list. If a command is unknown, the "no matching commands" item is shown.
2. Add placeholders to /ask and /fix queries to indicate they expect additional input (question or instruction).
3. Shows /ask and /fix as fallback items when no items match the query. Query is added to the corresponding quick-pick item label.

Screen.Recording.2023-08-30.at.15.36.03.mov

Test plan

Tested manually (video attached).

[toolmantim]

Lovely!

Tested locally and works great, except for one case I spotted: once you add arguments, it seems to fall back to the non-matching behaviour:

[taras-yemets]

Tested locally and works great, except for one case I spotted: once you add arguments, it seems to fall back to the non-matching behaviour:

@toolmantim, I think this behavior is expected. It checks whether the query matches either the label ("/ask") or the description ("Ask a question"), but not the combined string in any direction. So it doesn't match queries like "question /ask" or "/ask ask a question".
What do you think about it?
We control how the quick pick items filtering logic so we can tweak the logic described above.

[toolmantim]

@taras-yemets I've spotted another gotcha 😅 /ask doesn't actually support arguments, so showing the fallbacks in this way will be confusing:

In the design, the assumption was that you could provide arguments to both /ask and /fix… but it looks like it's only /fix that does.

I'd still like to get these fallbacks working well though… we're so close. How possible is it to add argument support to /ask as well?

Also i've just updated the Figma to resolve the filtering questions (what to do on no matches, invalid arguments, explicit /command invocation), and some labelling changes to make it clearer which commands support arguments. Unsure which changes to include in this particular PR, but hopefully that resolves the things we've learned/raised so far.

[taras-yemets]

In the design, the assumption was that you could provide arguments to both /ask and /fix… but it looks like it's only /fix that does.
I'd still like to get these fallbacks working well though… we're so close. How possible is it to add argument support to /ask as well?

@toolmantim, I think the /ask and /fix fallback options work similarly regarding commands. If a user selects any of them with an empty query, an additional input is shown asking for a question or instruction. If the query is not empty it's used as a /fix command instruction or a question submitted to the sidebar chat.

[taras-yemets]

Also i've just updated the Figma to resolve the filtering questions (what to do on no matches, invalid arguments, explicit /command invocation), and some labelling changes to make it clearer which commands support arguments. Unsure which changes to include in this particular PR, but hopefully that resolves the things we've learned/raised so far.

@toolmantim, great work, thank you! Addressed in the current PR (see updated description).

[taras-yemets]

@toolmantim, there is a nuance with the UI.
Placeholder (29-31 sec on video) and question/instruction body (9-11 sec on video) are parts of the item's label according to design. Item label is always searchable, and matches are highlighted with a font weight and color - default VSCode's quick-pick behavior.
Unfortunately, we cannot style quick-picks, so we can't change the markup and styles of its items (to do that, we need to reimplement the quick-pick from scratch).
This highlighting seems confusing to me.
Possible solution: render placeholder and question/instruction body as the item description. In this case, we can exclude it from search, but it'll bring style differences compared to the slash command which is rendered as a label. We can do all the content as description in this case, but then it'll differ from other quick-pick items.
What do you think about it?

[toolmantim]

This is looking great! 🎉 Nice one.

I gave it a go locally, and the highlighting can feel a bit weird like you said, but given it's pretty common VS Code quickpicks I reckon it's okay:

[toolmantim]

(Don't forget a changelog!)