Feature request: Support subcommands with arguments about lino HOT 3 CLOSED

I suppose with_argument('fake_argument') could be called outside of (i.e., after) the subcommand configuration block, but there could still be use cases where the subcommand's argument needs to come before the subcommand's options.

from lino.

Hi Naji,

Thanks for raising the issue. I have a few questions on what you'd expect here. Let's say a command uses a structure that has sub and sub-sub commands:

command = Lino::CommandLineBuilder
    .for_command('x')
    .with_subcommand('y')
    .with_subcommand('z')

Today this produces x y z. Now, let's say we allow each of those to have arguments:

command = Lino::CommandLineBuilder
    .for_command('x')
    .with_subcommand('y') do |y|
      y.with_argument('a')
    end
    .with_subcommand('z') do |z|
      z.with_argument('b')
    end

What would you expect the command to end up as? x y a z b?

There's then a risk of misinterpreting arguments as subcommands and vice versa. It's for this reason that most commands expect or at least allow all arguments to come last after flags and options. And it's based on this that arguments is considered a top level method rather than a subcommand method.

Let me know your thoughts,

Thanks,
Toby

from lino.

Hi Toby,

Thanks for the prompt reply! That's fair; I hadn't considered that ambiguity.

FWIW, I would expect x y a z b. I would expect that the command (y in this case) would correctly interpret a as an argument if y was indeed expecting it. If y was not expecting argument a and so misinterpreted a as an (invalid) subcommand, I would expect y to emit some error and halt. i.e., I consider it the user's responsibility to build a well-formed command for their use case.

But I do see the drawbacks, and the command I'm trying to use does indeed allow arguments to come last, so I'll close this out!

Thanks!

from lino.