| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
| |
The previous change to properly format the help text for optional
arguments left one thing out: parameters that are based on an Option as
opposed to an enum. The problem with those is that we cannot simply ask
the value (i.e., the Option) for all the variants of the inner type.
Instead, we have to reference the actual type of the inner enum in order
to retrieve all its possible variants.
|
| |
|
|
|
|
|
|
|
| |
With the ability to fully generate the command enums we use for working
with the argparse crate, we can now take things one step further and
populate the contents of the help string we print for the user that
lists the available commands.
Doing so we also fix a bug where we forgot to mention the "storage
status" command in the help text.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not too long ago we added a macro to auto generate the command enums and
the required trait implementations from a concise declarative
representation. This change extends this mechanism to the execute method
implementation that some of those enums provide.
When a tuple is specified as the "destination", e.g., here:
> Enum! {ConfigCommand, [
> Get => ("get", config_get),
> Set => ("set", config_set)
> ]}
the second component of this tuple will be interpreted as the function
to invoke when this variant used in the newly generated execute method.
|
|
|
The argparse module we use for parsing events expects an enum in order
to convey what subcommand has been supplied as an argument. Such an enum
also needs to implement str::FromStr and, preferably, fmt::Display.
Manually writing down those definitions is error-prone, tedious, and
adds no value -- only lines of code.
As it turns out the proper definitions can be generated with relative
easy with a declarative macro, making the code much more concise. Hence,
with this change we use a newly introduced macro for generating those
enums.
|
