`--help` on the multicommand programs without the command should at least list the available commands

[SolitudeSF]

for real

[c-blake]

I am not sure what you are asking for here. For me, with no commands/args at all it prints a brief summary listing subcommands. With help it dumps a comprehensive help message. For any individual subcommand you can get help via mainCmd help subCmd or mainCmd subCmd --help.

While I do understand there are other toolkits with various behaviors, I do not think there is much even of an evolved standard in this space.

[SolitudeSF]

true, without any arguments it does list subcommands. but my instinct was to do --help. with just --help it lists bare minimum. and i didnt know about help subcommand.

[c-blake]

This is also already mentioned in the README. I can look into making --help act more like no-args, but I'm not sure that's easy to do.

The lack of a standard is what fights against "instincts". But even GNU long --options are not really "standard", either. :-(

[c-blake]

At first I thought the README was just overoptimistic (and already changed it..), but really multiCmd --help is already supposed to emit the top level table. Even now, it "sort of" works - e.g. if you set CLIGEN=/dev/null runMultiCommand --help. Something about a config file can break that logic (and is not tested by test.sh which turns off the config/colorization so as to use a "standard output").

Will have to track this down..Sorry. I always just run with no args and forgot this was supposed to work until I looked at my test/ref output (which just runs everything with a nim c --run --help, plus dispatchMultis get an extra test case of multicmd help).

[c-blake]

Yeah..If you just comment out any use= in the [templates] section of the config file then things work as you originally expected { or perhaps even remembered ;-) }.

[SolitudeSF]

yep, i was guessing that probably my config interferes with this. is there a "default" use template that i can just add the colors to, or does it interfere with full help?

i havent looked at the config file for the longest time, so i didnt remember initially how its organized. this my current use: use = "$command $args\n\n${doc}\noptions:\n$options". is anything missing?

[c-blake]

I have a fix that I think is ready to go, actually. The problem line is https://github.com/c-blake/cligen/blob/master/cligen.nim#L551 but I don't think anyone but dispatchMulti is likely to call a parser-dispatcher with a custom usage string, and regardless it is better to prioritize the run-time passed usage to the other. So, I think by just giving priority to usageId there your problem will just go away and you won't have to do anything except update cligen.

[c-blake]

(To answer your question, at present if you set [templates].use to anything non-empty then it blocks the dispatchMulti-passed generated value. Sorry, I was multi-tasking when editing that last response.)

[c-blake]

FWIW, I also set [templates].use (to strip the Options: bit which I find redundant upon having colorized help). So, I had been seeing this problem for a long time and forgot the non-colorized mode worked at all.

In fact, I have been thinking of adding a way to drop the --help and --helpSyntax rows in the user config since I can tell if it's a cligen program from the colorization of the help message. Really, many people probably could from the "type" column, actually. { EDIT: As a minor point of clarification, [templates].helpSyntax = "" will totally disable --help-syntax {not sure that's documented anywhere}, but I think it might be nice to disable just the help table row but leave it as a "hidden option". There is no way currently to remove/make hidden --help at the user-config level. You can as a CLauthor, but whether you want to see it or not is often more an end-CLuser question. }

[c-blake]

I think it all should work again if you re-compile with the git HEAD. Thanks for reporting this problem. As I mentioned, I had sort of noticed it and forgot it was supposed to work. I guess I was too dazzled by my colors. ;-)

BTW, I didn't mean to insult your "instincts". It's just a hard problem space in general because everyone brings their assumptions about Python toolkit X or Go toolkit Y or Rust toolkit Z. Few realize POSIX never got around to anything beyond the single-dash 1-letter options and double-dash options-args separator. This is made worse since the very moment when you employ said assumptions is exactly when you are frustrated as a CLuser and want CL help. But there is never anything wrong with generated help striving to be helpful. I had even started looking at another fix when I noticed my test/ref did the right thing.

[c-blake]

I have a release sort of queued up, but it might be best if you first confirmed the new code works for you before I punch it. Thanks.

[SolitudeSF]

it works, but i noticed that $command variable in useMulti template doesnt preserve color when printed.

and looking at my terminal history, it was probably always discolored, so its unrelated issue.

[c-blake]

Yeah. I do like the rendering system as an output/in-terminal documentation niceness and I know at least @Vindaar and @kaushalmodi also do, but it is definitely still a WIP. I have a few informal colorization things in a little todo file at home. Looks like this right now, but I will add your $ expansons-not-always-rendered point:

  colorize help for the catch-rest parameter
  colorize suggestions for mispelled things
  Cannot colorize w/o guidance, but at least otherwise de-backslash

If anything bothers you particularly more than the others, I'd be happy to guide a PR. For now I will push this release, though.