make blisp help Usage message consistent

[River-Mochi]

Enhance the help messages for Blisp if someone types the incorrect command or spelling error.
This is somewhat related to the PR I submitted today. I corrected the readme page, but it would be nice to have a correction on the CLI help message.

Background:

• syntax error in main Readme instructions I corrected today. If flag --chip is used it needs to be --chip=bl70x with the "="
• does not work: blisp write --chip bl70x --reset name_of_firmware.bin
• if "=" is not desired then "-c bl70x" could be used instead.

Either of these work for windows powershell:
-c, --chip=<chip_type> Chip Type

I noticed in using Blisp today the following:
If you type the flag incorrectly then it gives you one set of instructions. but if you mispell a word, then it gives you different instructions (see screenshot)
"Usage:" message should be same for both mistakes so user gets consistent help information.
It would be nice if both errors had a combination of the help lines, see my recommended update below.

Example below for improved message, just have this consistent message for the errors instead of two slightly different error messages for misspelled word versus a flag syntax error.

Usage:
  blisp write -c <chip_type> [-p <port_name>] [--reset] <input>
  blisp iot -c <chip_type> [-p <port_name>] [--reset] [-s <file>] [-l <int>]
  blisp [--help] [--version]
Writes firmware to SPI Flash
  -c, --chip=<chip_type>    Chip Type
  -p, --port=<port_name>  Name/Path to the Serial Port (empty for search)
  --reset                   Reset chip after write
  <input>                 Binary to write

[gamelaster]

The thing is that this is fully controlled by argtable3 library :(

[robertlipe]

I think River's point is that the help (which we ultimately control) doesn't match reality. We don't have THAT many arguments. If argtable is dumb and prints help in a different format than it actually parses it (seriously?) we can make https://github.com/pine64/blisp/blob/2141e33c2bf4f513a07554cd4ee13b8b2ff62d7f/tools/blisp/src/main.c#L31 just print a sensible usage message. I understand the desire to DRY and let it handle it, but if print_help() just needs to output four literal lines of help (that match what we recommend and what works) I can sling that patch later in the day.

…

On Fri, Feb 17, 2023 at 8:47 AM Marek Kraus ***@***.***> wrote: The thing is that this is fully controlled by argtable3 library :( — Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD32TGQ4UABJ5G6XBWE3WX6FP7ANCNFSM6AAAAAAU5NT2K4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[robertlipe]

Wait. From where does args_pritn_syntax() come? Doesn't look like it's in argtable... https://github.com/argtable/argtable3/search?q=args_print_syntax ...and I don't see a definition of that in my work tree. I guess later in the day I'll try to lock it in a debugger and see who is really printing it and how if this is something that we need to fix. (And based on River's description, I think we should...)

…

On Fri, Feb 17, 2023 at 10:56 AM Robert Lipe ***@***.***> wrote: I think River's point is that the help (which we ultimately control) doesn't match reality. We don't have THAT many arguments. If argtable is dumb and prints help in a different format than it actually parses it (seriously?) we can make https://github.com/pine64/blisp/blob/2141e33c2bf4f513a07554cd4ee13b8b2ff62d7f/tools/blisp/src/main.c#L31 just print a sensible usage message. I understand the desire to DRY and let it handle it, but if print_help() just needs to output four literal lines of help (that match what we recommend and what works) I can sling that patch later in the day. On Fri, Feb 17, 2023 at 8:47 AM Marek Kraus ***@***.***> wrote: > The thing is that this is fully controlled by argtable3 library :( > > — > Reply to this email directly, view it on GitHub > <#20 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACCSD32TGQ4UABJ5G6XBWE3WX6FP7ANCNFSM6AAAAAAU5NT2K4> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

[River-Mochi]

I can sling that patch later in the day.

that would be nice if you could update the code to have help message be consistant for all mistakes. and give the user all the info possible.

I'm not sure where this is exactly in the code. could you give me a link to where this is? is it something where we can type in the help message we want?

[River-Mochi]

@robertlipe have you attempted to change the help output messages in BLISP ? any progress on this?

[robertlipe]

I've begun an investigation (NTS: ~/tmp/blisp-notes) and I'm finding substantial disparities between what's accepted, what's displayed, and industry norms. I'm not typing it here at this time, but there are at least a few things we can do that will help improve usability, but I can't even make it work reliabily enough to root cause it right now.

Investigating.