I recently modified the find plugin to add the --full-path arg to the underlying fdfind CLI.

In doing so, it seemed to me there were really a lot of options that could be quite reasonable for fdfind, notably the --glob parameter, which makes the launcher's find command behave more like a command-line pattern match (as opposed to the regex style pattern match that is currently the default).

My first impulse was to make the find command take a config.ron that allows to choose glob vs regex. However, I realized the entire find plugin is a great example of a potentially reusable pattern--

1. Given a CLI command that lists results as output (e.g. fdfind)
2. and a set of arguments to pass in as defaults (e.g. --full-path, --regex, --glob, etc.)
3. pass the search-term as last argument to the CLI tool
4. display each line from STDOUT as a corresponding result in the launcher
5. pass the result to a command to run when executed

To my surprise, this pattern is actually already built for URLs--it's the web plugin! We just need something that behaves this way for CLI tools.

Would it make sense to either

• (a) modify the find plugin to be more versatile so that it has a config.ron similar to the web plugin, but to use CLI commands instead of xdg-open, or
• (b) create an entirely new plugin that does the same?

I'm kind of thinking (a) makes more sense since if I build this, then the current find command would become simply a setting to add to the config.ron of this modified plugin (i.e. the modified plugin would functionally be a superset of the find plugin).

Any thoughts or guidance before I dig in?