Before I begin, I should note that this is not a request for someone else to implement a feature. I have already implemented this feature in my own fork, and can submit a PR if core devs are interested.

Description of the Issue

Currently the shortcut mapper filters using the entire contents of the Filter search box (I will hereafter call this filterStr). If any field for a shortcut contains filterStr in its entirety, the shortcut is displayed.

This behavior is fine, but there are many times when a more flexible system would be useful. A simple, user-friendly way to do this is to split filterStr into a list of whitespace-separated words (I will hereafter call this filterWords), and then require every word in filterWords to be matched by at least one field.

For example, let's look at a screenshot from 8.5.8.

I have used the jsont search term to find all the shortcuts associated with the JsonTools plugin. But JsonTools has a lot of shortcuts, and maybe I want to see all the JsonTools shortcuts that relate to regex. With the current implementation, this can only be done manually.

Here's a screenshot showing how to do exactly that with my proposed implementation.

Hopefully the advantages of the new behavior are obvious.

Disadvantages of the proposed behavior, and my counterarguments

1. It's different from the existing behavior, and would cause initial confusion.
   • Anything matched by the existing behavior will still be matched by the new behavior. For example, suppose the user wants to find a shortcut called csv to json, so they input csv to json. The new behavior will match csv to json, but it will also match any shortcut containing the word csv associated with the JsonTools plugin.
2. Literal space characters in the search term are no longer matched.
   • I think this is a pretty niche case.
3. It might make performance worse.
   • I tested it. There's no obvious difference.
4. It makes the code more complex.
   • my current implementation causes a roughly 20-line diff, including about 20 changed lines in ShortcutMapper.cs and 2 changed lines in ShortcutMapper.h. About half of the new lines are explanatory comments.
   • in addition, the changed functions are only called in ShortcutMapper.cs, which is a modal dialog, meaning that ripple effects to the broader codebase are essentially impossible.
   • However, the code footprint gets a lot larger if a new setting is desired to allow toggling between the old behavior and the new behavior (say, maybe a checkbox next to the Filter textbox). For this reason, I would prefer to avoid adding a new configurable setting, especially one that is saved to a config file.