reeflective/flags

Generate cobra command trees from structs. Go-flags compliant tags. Advanced CLI functionality, out-of-the-box.

flags's Issues

Use the `flags.Value` interface for positional argument types

Currently, the code parsing the positional argument words (strings) onto their type is directly taken from
the old go-flags code. While not working badly, the range of types supported is largely inferior to the range
of types supported for flags.

This is not really hard, and should not represent a huge workload.
I just realized this would be better toward the end of my work.

• Use the flags.Value type for generating positional arguments slots and parsing words onto them.

Better handling for some positional edge cases or invalid setups

Currently there are two cases in which the command scan should return an error and does not:

• When two slices have no maximum requirements.
• No max on slice where there is another field after it, and no global requirement.

Other than that, there is still some edge cases for positional parsing.
Most cases work fine, and are covered by tests.

Enable combining tagged completions with types' implemented ones

Currently, tagged completion directives have precedence over any completer interface implemented by the type being tagged (as flag or positional). Using a complete:"+CompleterName" should enable stacking both the tagged directive and the type completer

Uniform *Group/*Command treatment

General problem

For as long as this library exists the *Command and the Group type have had partially overlapping roles,
since *Command embeds a *Group for storing its struct data and various other attributes, but this has
introduced a little flaw that Cobra has avoided: purely arbitrary declaration/parsing/lookup of subcommands/groups/options.

Below is an attempt at explaining this issue, what lacks and what causes (please blame me for my lack of clarity):

Grouping commands

• There isn't therefore a pure way of structuring commands in a way similar to options: there is a similar
  mechanism, but not quite the same. Currently, you can declare a subcommand to a command with an appropriately
  tagged struct field, given the host struct itself is a valid command, but you can't do this if your child
  command is embedded in a struct that you will add as a group.

Namespaced options

• As far as the *Group type is concerned with options, there are absolutely no complaints to be made. Everything
  is made and works according to what users of this library want. However, the new version of this library introduces
  a new way of declaring namespaced short options. This is mainly for purpose of easing how to declare various options
  arguments/switches (such as an option -P accepting a single-rune argument, like -Pn -nmap's users hello- and yet another
  optional argument to the n switch, such as port list).
  But sometimes the -P -as in nmap's case- has many different suboption switches, which you want to give a bit of structure.
• For these purposes and that of advanced completion support, this library has only very partially rewritten the way option
  groups make their lookups. This is partially the reason why this issue is created: because it's not unified anymore.

Proposals

To speak of implementation details briefly: binding a command will scan the corresponding struct for both subcommands
and option groups (arbitrarily nested), while binding a group of options will only scan for namespaced option groups (childs).

Goals

• This library should scan arbitrarly structured commands/groups/options implementations within a host struct.
• Users will then be able to further group their sets of commands into a host struct to register to a root Parser (or command).
• This, in the end, will sound very familiar to Cobra users, which has reached this recursive, arbitrary way of parsing/looking up.

Tasks

• Refactor the _ struct scanning_ code such as an arbitrary struct can hold commands and/or option groups and/or subgroups of both.
• Add the corresponding tags and the code needed to interpret them correctly.
• Probably as a consequence and in this respect, refactor the commands/options lookup code (used both for parsing and for completion).

Consequences

• As a result, "there should be more ways to do one thing". Although I don't explicitely intend this to be so, or want it for its own sake,
  I first want to warn about it, so that shortcomings and pitfalls shall be avoided when possible, as is the practice with Go in general.
• More concretely, some struct tags might have a different meaning depending on which field/type they qualify: this already the case for tags
  like description:"bla", optional:"yes", etc. However such a change will apply to new tags such as group:"name", where the group
  can be either a group of commands, a group of options, or even a group of groups. If this same group tag is used with a command, it could be
  used to specify the "tag" for the command (used to structure completions and help output).

Harmonize NoSpace directives with options

When an option Path has both -p/--path flags, when having inserted -p and hitting TAB will not either space it (accepting this short option, not colliding with any other than its long-name alias. This should be harmonized, probably through zstyle instructions given with above any group (like if no other match than your own alias, you're good to go)

Check that all new Command fields from Cobra are used correctly

Many fields of the cobra's Command type have been merged into our own command type. Most of them are not used at the moment, while they should. Verify and use them accordingly.

Remote = sign from options in help by default

Unless the option specificaly requires an = sign between it's name and its arguments, remove it from help usage. Probably will cross with how this sign is handled in the completions, depending on the option's requirements and stuff

Remove -h-/--help options category from default usage

Currently the "Help Options" category, which contains only a -h/--help flag, should be removed from the default usage printing

Wrap errors thrown option validators

In option.go's last method isValidValue(), we should wrap the error returned by the implemented ValueValidator of the option.

Refactor parser per-command (cascading)

The parsingState object should be passed from command to subcommand (each time one is found), so that parsing can be operated similarly to Cobra. \n This does not change the fact that a Client type is still needed for parsing a command line.

Tests to write

Some tests should be added to the library:

• Make/autogenerate test functions for when people use custom flag types
  (which must therefore implement the flags.Value interface), that are
  actually NOT implementing the value, so that we don't have to panic.

Implement kong-style positional arguments

Kong (and probably other libraries) do not require developers to encapsulate their positional arguments into a specific struct. This has the advantage of being simpler when the positional structure is not sophisticated. In addition, people are probably used to this.

• Implement kong-style positional arguments

Enlarged tagged completion directives

Currently, completion directives that used through struct tags are restricted to a few ones.

Two sorts of enhancements could be thought of:

• Enable users to declare custom completer functions through tags, and then to bind those
  functions (implemented elsewhere) through the carapace engine.
• Since the carapace-bin repository declares litteraly hundreds of system completers,
  we should find a way to enable using them through struct tags. Probably just need
  to declare a map somewhere with all the relevant ones.

Devise if parseState.addArg should return an error

The function parseState.addArg(arg) stores significant errors into itself, but returns an error nonethless, which is not uniformly checked/handled across the codebase. The situation has been slightly enhanced, but probably not optimal yet.