> I think the command-line.parser vocab works as-is, but it's a little > unwieldy and maybe more fragile than it should be. Improvements and > PRs welcome. > > Let me know how that works (or not) for you. > > Thanks, > John.
On second thought, while the help text is working as expected & CONSTANT: COMMANDS *looks* about what I expected, the actual usage / ergonomics are not what I expected. Maybe I am using it wrong… I did hdo catch the post via Atom in my feed reader: https://re.factorcode.org/2025/07/command-arguments.html For one: > There are other features we might want to add to this including > per-command metadata with a brief description of the command, support > for additional top-level options besides just the command, and perhaps > a different way of handling the no command case rather than empty > output. Regardless of whether going ``foo add`` or ``foo substract`` there is still value is top-level flags beyond ``--help`` — namely ``--version``. I wouldn’t expect to need to add ``--version`` flags to both ``add`` & ``subtract``, & while I could, downstream users would be confused that they need to use ``foo add --version`` or ``foo substract --version``, but not ``foo --version``. As a developer, I need to choose to opt into ``with-commands`` or ``with-options`` as either will fail if parsing came up blank. I can assume there is a try-catch mechanism that could be used to run ``with-options`` first for top-level, then try ``with-commands``, but that doesn’t seem like the intended UX but a hack. The options type is ``{ T{ } }``, but commands is ``H{ "" { T{ } } }`` so they can’t intermingle (which is why I had mentioned ``commands`` as a possible option type in the original email rather than a separate parsing style one must choose between). Secondly: I can’t just have a bare command like ``version`` that prints the version (in lieu of no ``--version``). An option would be like .. code:: factor SYMBOL: version MAIN: [ H{ { "version" { T{ option { name "--version" } { type boolean } { default t } { variable version } } } } { } [ version get . ] with-commands ] With like a phantom default boolean that could be checked, but it this definitely feels like another hack. Leading to… Thirdly: Maybe the UX is off entirely as I would assume subcommands would lead to their own branches like .. code:: factor H{ { "add" [ ! call this quotation for “add” options ] } { "subtract" [ ! call this quotation for ”substract” options ] } } TOP-LEVEL-OPTIONS with-commands-&-options where the inner quotations might behave like ``with-options`` on their respective options a bit like ``cond`` traversing/dispatching on the hashmap rather than a flattening of say ``SYMBOL``s at the global level & tons of if null checks to try to guess the user’s intent. With a UX more along these lines, I think the ``foo version`` (or whatever bare command one could want) would have been covered since its options could have been left empty rather than the phantom ``--version``. It also could avoid series of global checks as once in the ``add`` branch, all other branches are definitely irrelevant & shouldn’t be checked. — toastal _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
