[Ovmsdev] Addition to OVMS Developer Guide
dexter at expeedo.de
Fri Jan 1 18:38:37 HKT 2021
Am 01.01.21 um 02:34 schrieb Stephen Casner:
>> Regarding command options: for my latest command addition (obdii requests) I
>> checked if we can use getopt_r(). Problems are a) it's not in the newlib
>> included in esp-idf, and b) we also would need to change all handler
>> signatures to allow getopt to modify the argv array. I also checked if some
>> clever C++ getopt class is available but found none.
> Another option (pun intended) would be to stick more with the original
> parser design with trailing positional optional parameters rather than
> prefix option flags. Option flags are familiar to many of us
> developers, but that might not be the best choice for implementation
Positional optional parameters don't grow well for multiple options,
force users to a fixed argument scheme and tend to produce hardly
readable commands. I also think command options are for
experienced/advanced users, and those are familiar with the concept.
Extending the parser to support command argument templates would be an
option, but I had the impression that would add a lot of complexity, and
would only benefit a small set of (advanced) commands. (Side note:
regarding command templates, I really liked the AmigaOS template scheme,
IMO a shame it didn't get adopted more widely.)
> Now, I'll admit that the obdii command has complex options that may
> need to be implemented as you have done. However, let me cite one
> Usage: event raise [-d<delay_ms>] <event>
> This could have been done like homelink:
> Usage: homelink <homelink> [<duration=1000ms>]
> The latter form would be cleaner in that you wouldn't have to type the
> -d prefix. Also, the tab completion that I implemented before you
> added the delay option is now broken, although it would not be hard to
Agreed for the case of a single option and a command that's not supposed
to grow any new features. I did so on some of the CANopen commands. But
imagine we need to add another numerical option to "event raise": nice
and clean by prefix options, a usability nightmare with positional args.
I wasn't aware of the tab completion on "event raise"… I normally use
the command to raise custom events only. I'll fix that.
> With the flexibility to have intermediate parameters now, using the
> validate function, it may fit reasonably to have the options handled
> by a subtree.
> -- Steve
Do you mean a secondary option subtree triggered by the "-" prefix,
inherited to the regular command subtree?
That would allow simple tab completion on options as well… sounds like a
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 203 bytes
Desc: OpenPGP digital signature
More information about the OvmsDev