Proposal: Make the `find` built-in more versatile

[canadaduane]

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?

[mmstick]

I'm open to the idea. I've had on my backlog of ideas to integrate Rhai into the launcher so that plugins can be written as Rhai scripts internally executed by the launcher.