I have been trying to hack on command-line.parser to add the ability to call it with commands. I am too far out of my depth in both understanding how to debug the situation, but also it’s difficult to work with since all of the vocabs are used for the listener already it seems?
Ideally the API goal would be like OCaml’s Cmdliner Cmd <https://ocaml.github.io/odoc/cmdliner/cmdliner/Cmdliner/Cmd/index.html> which is for CLIs that aren’t prompt-based, command-driven such as with Git, Pijul, & so on. Currently there is no ordering of arguments as you are either an option or positional, but command styles have recursive units that can nest other options / commands which could have their own help texts — where once a cmd type is found on in the set of commands from the argument sequence, the rest of the arg sequence should run (parse-arguments) on a new options for the command. Some tools like Git & Pijul can dispatch out from a primary program to subprograms based on the name, but if start times are slow or executable sizes are big, this isn’t as preferred by users, which is probably the case for Factor — especially if using the interpreter as factor -run=foo bar baz --qux "quux" (would this then call factor -run=foo.bar baz --qux "quux" which then calls factor -run=foo.bar.baz --qux "quux"?). What I intially tried was using -- to get the rest of the arguments, but aesthetically this isn’t ideal, but more importantly you would lose the ability to get help text for the subcommands. --help currently can *only* show the top-level help & it can’t be surpressed while all much of the API is hidden behind <PRIVATE> to try to assemble the pieces yourself. -- could also be assed to a prompt-based setup as input, like fdisk. Is this a feature request, a call for help? I’m not entirely sure… 😅 but it does seem the like a missing feature that could be tackled for UX as prompt-style CLIs have gone out of fashion & folks — my Fish session included — want shell completions without wrangling the state of a prompt (I have failed to set up a disk with fdisk on more than one occassion). … Or should I just be doing my own argument parsing & avoid command-line.parser (recently moved from /extra to /basis) if it can’t fit my needs? --- I had written a single test as a goal: CONSTANT: COMMANDS H{ { "add" H{ T{ option { name "a" } { #args 1 } { type integer } } } } { "subtract" H{ T{ option { name "s" } { #args 1 } { type integer } } } } } { { H{ { "cmd" { "add" H{ { "a" 1 } } } } } H{ { "cmd" { "subtract" H{ { "s" 1 } } } } } } [ { T{ option { name "cmd" } { cmd COMMANDS } } } { { "add" "1" } { "subtract" "2" } } [ (parse-options) ] with map ] unit-test As well the type I would assume… TUPLE: option name type help variable cmd default convert validate const required? meta #args ; TUPLE: command name help options ; But got stuck trying to figure out where / how get this in parse-arguments. _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
