The plugins are currently shown only if their regex is matched. While this covers many use cases, there are already some plugins that only match when the query beings with / and then matches some pattern. Examples:
Google search: /g or /google
DuckDuckGo search: /d or /duck /duckduckgo
Tab actions: /t or /tab
As the number of plugins increases, there will be cases where multiple plugins match similar patterns (if they are small). To resolve this plugin searching can be added for these special types of plugins that begin with /.
Proposed solution :sparkles:
Similar to the autocomplete menu in code editors, a special plugin search menu may be shown when the query begins with / which would show a list of plugins that are currently active.
Typing anything after / would be considered as a query that would search in the list of plugins. When the user chooses a plugin (using arrows to navigate and enter to select), all items related to only that plugin would show up.
The user can then continue typing the query to search through the plugin items (similar to the current behavior).
But doesn't this seem like increasing the steps to search for something? :thinking:
It initially did feel as if the number of steps would increase. But thinking about it more, it actually doesn't! When regex was used for matching patterns, the user had to be careful about what they are typing (so that it matches the pattern and shows the results). Whereas in this approach, after typing / plugins would be fuzzy searched against the query thus decreasing the scope of errors. Selecting the plugin might feel like an extra step but selecting a plugin would just be Enter which technically replaces Space usually needed after /g or /d right now.
What would the plugins be searched against? :thinking:
Plugins would be searched against their display name (which is shown to the user) and a set of keys defined for the plugin. Example: for Google search plugin, it could be [ 'g', 'google' ].
Current problem
The plugins are currently shown only if their regex is matched. While this covers many use cases, there are already some plugins that only match when the query beings with
/and then matches some pattern. Examples:/g or /google/d or /duck /duckduckgo/t or /tabAs the number of plugins increases, there will be cases where multiple plugins match similar patterns (if they are small). To resolve this plugin searching can be added for these special types of plugins that begin with
/.Proposed solution :sparkles:
/which would show a list of plugins that are currently active./would be considered as a query that would search in the list of plugins. When the user chooses a plugin (using arrows to navigate and enter to select), all items related to only that plugin would show up.But doesn't this seem like increasing the steps to search for something? :thinking: It initially did feel as if the number of steps would increase. But thinking about it more, it actually doesn't! When regex was used for matching patterns, the user had to be careful about what they are typing (so that it matches the pattern and shows the results). Whereas in this approach, after typing
/plugins would be fuzzy searched against the query thus decreasing the scope of errors. Selecting the plugin might feel like an extra step but selecting a plugin would just be Enter which technically replaces Space usually needed after/g or /dright now.What would the plugins be searched against? :thinking: Plugins would be searched against their display name (which is shown to the user) and a set of keys defined for the plugin. Example: for Google search plugin, it could be
[ 'g', 'google' ].