Added fuzzy string matching, we now check for duplicates and commands with isChecked(...) == true show up with a little checkbox.

@dacap AFAIK there's no way to check if a command is functions like a "toggle", you can call isChecked to know if it's checked, but there's nothing you can call to see if we should show an empty checkbox or maybe do the toggle inside the runner without leaving, might be worth seeing if we wanna add something like Command::isToggleable() to distinguish them?

This looks great 🚀

Added fuzzy string matching, we now check for duplicates
and commands with isChecked(...) == true show up with a little checkbox.

Nice!

@dacap AFAIK there's no way to check if a command is functions like a "toggle", you can call isChecked to know if it's checked, but there's nothing you can call to see if we should show an empty checkbox or maybe do the toggle inside the runner without leaving, might be worth seeing if we wanna add something like Command::isToggleable() to distinguish them?

We could change the isChecked() return value to std::optional<bool> probably, but I'm not sure if we should show an unchecked box for these togglable commands (as I think an empty box will be confusing for these cases). At the moment I'd avoid this.

Some notes:

1. probably the =... syntax is not needed, we can just evaluate the expression and if the expression works and is different to what is written, we show the result (+search for commands, just like google works).
2. We can set Ctrl+Space as the default shortcut for this.
3. Should we order things by menu order? For example, if we search for open
   
   "Open sprite" is a good first candidate and "open browser" isn't (as it requires parameters too).

Adjusted things to avoid listing commands that need parameters to function (added a few missing onNeedParams() implementations), tweaked the search score a bit so it prioritizes commands of similar length to what you're typing to mitigate your case, although at this point I might rethink the whole thing cuz it's getting a bit arbitrary maybe?

probably the =... syntax is not needed, we can just evaluate the expression and if the expression works and is different to what is written, we show the result (+search for commands, just like google works).

Personally I like it better with the prefix because it clearly delineates things as separate "mode", like the Lua expression editor and more importantly makes the code simpler and more readable IMO, it's already a bit complicated as it is. We're also already doing a bunch of things on every Entry::Change so I'd like to avoid doing more, I picked "=" since it's what you to use to do math in Excel formulas so it might be familiar to some.

I think it's working great 👍 we can merge it as it is (you can move this to "ready for review") and I'll merge it just in case something is missing.

After this is merged I'll make some little changes to the window title bar to reduce a little the translation/i18n work.

Great! I've marked it ready for review and I'll get to writing the documentation so the "?" button doesn't link to a 404 page