Anyway, thoughts behind this approach?

This basically allows you to specify command line flags on a per-plugin basis. Default implementation allows you to simply set config properties as if you're typing lua.

It's very simple, but fairly powerful. Has the advantage of consuming flags directly, meaning that there's no complicated system for managing anything, and we can still report on unconsumed flags.

There's some issues relating to which project you're in, as in order for plugins to consume flags and determine load order, we need to load the project module first; meaning that we have to be careful about how we specify things on the command line; anything that looks like a filepath, even if it's an argument to a string argument would cause us to load that particular project. But this is a somewhat core-level problem.

Obviously we should probably include stuff like --x and --y and --help and whatnot.

For reference I'm leaving this here as the approach taken on pragtical pragtical/pragtical#28 the API is documented on the PR using lua doc comments with some basic usage example provided. Some of the features it supports:

• Default command that provides --help --version and can be manipulated by plugins to add more flags/functionality
• Additional commands registration support (each command can have their own flags and subcommands)
• Support specifying the max and min arguments supported by a command
• Recursive subcommands support eg: app_binary command1 command2
• Automatic flags type checking and error reporting
• Flag types supported: empty, number, string, boolean, list
• Automatic help generation for registered commands
• Colorized help output
• When a command is found on the args list the associated callback gets automatically executed receiving the found flags and arguments
• Ability to specify if when a command is executed the editor should exit.
• etc...

Some example of live plugin (editorconfig) PR adapted to optionally use the CLI API when available pragtical/plugins#4