On Thursday, 3 March 2016 at 15:08:37 UTC, Jacob Carlborg wrote:
> Does it support some longer documentation for the flags, i.e. "git status -h" vs "git status --help"?

Yes.  You can give an option a description, like this:

// ...
uint nr_doors;
// ...
Named("doors", nr_doors, 0) ("number of doors").AddRange(1, 4);

If you do this, the user has a nice, short name to type:

--doors 2

But the description will be used in error messages ("The number of doors must be between 1 and 4") and in auto-generated syntax summaries ("--doors <number of doors>").

For a positional parameter, the user never types the name, and so you just do this:

Pos("number of doors", nr_doors, 0).AddRange(1, 4);

Then the syntax element we auto-generate will be "<number of doors>" and error messages will be the same as for the equivalent named option.

Markus

On 03/03/2016 04:09 AM, Markus Laker wrote:
> On Thursday, 3 March 2016 at 01:52:11 UTC, Chris Wright wrote:
>> You might want to take a minute to shill it here. What's great about it?
>
> OK.  :-)
[snip]

Very nice! I think we should adopt some of these ideas for std.getopt as well. -- Andrei

On 2016-03-03 21:55, Markus Laker wrote:

> Yes.  You can give an option a description, like this:
>
> // ...
> uint nr_doors;
> // ...
> Named("doors", nr_doors, 0) ("number of doors").AddRange(1, 4);
>
> If you do this, the user has a nice, short name to type:
>
> --doors 2
>
> But the description will be used in error messages ("The number of doors
> must be between 1 and 4") and in auto-generated syntax summaries
> ("--doors <number of doors>").

No, I mean a longer description, more like documentation. Look at the help for git when using --help, it has different behavior than -h. The first one is more like a man page.

-- 
/Jacob Carlborg

On Friday, 4 March 2016 at 12:21:25 UTC, Jacob Carlborg wrote:
> No, I mean a longer description, more like documentation. Look at the help for git when using --help, it has different behavior than -h. The first one is more like a man page.

Ah, I see.  Sorry for the misunderstanding.

An app could do that trivially: have a --short-help option with shortcut -h and a --help option with no shortcut, and then respond to the two switches differently.  Mark the --short-help option as undocumented, and then it won't appear in an auto-generated syntax summary.

Markus

On Friday, 4 March 2016 at 17:34:08 UTC, Markus Laker wrote:
> On Friday, 4 March 2016 at 12:21:25 UTC, Jacob Carlborg wrote:
>> No, I mean a longer description, more like documentation. Look at the help for git when using --help, it has different behavior than -h. The first one is more like a man page.
>
> Ah, I see.  Sorry for the misunderstanding.
>
> An app could do that trivially: have a --short-help option with shortcut -h and a --help option with no shortcut, and then respond to the two switches differently.  Mark the --short-help option as undocumented, and then it won't appear in an auto-generated syntax summary.
>
> Markus

I think he meant: [git status --help], where you have three attributes with the last one being the flag. So in addition to: [status --help] by default, you also have: [git status --help] to get help on status only.

By the way, that styles used by git seems confusing. Why not make it show the default help when you do: [git --help], whilst you can do: [git --help=status] OR [git --help status] for help on status only?

git --help
git -h

git --help=status
git --help status
git -h=status

On Saturday, 5 March 2016 at 16:28:25 UTC, karabuta wrote:
> I think he meant: [git status --help], where you have three attributes with the last one being the flag. So in addition to: [status --help] by default, you also have: [git status --help] to get help on status only.

Odd: I wrote a reply to this a few days ago, and it's nowhere to be seen.  I'll save a copy of this reply until I see it appearing on the forum.

Argon doesn't directly support subcommands.  That probably stems from a bias of mine: that subcommands make it harder for the author to parse the command and to generate good error messages, and also that they make it harder for users to use unfamiliar commands, because users must read a man page that documents eleven things they have no interest in doing just to get to the one thing that they need to do in order to get on with their day.  At work, where I have written and I still maintain many hundreds of commands, I've moved away from subcommands completely: every operation gets a command of its own.  But I know that not everyone agrees with me, and that's OK.  If we want to debate this topic further, we should probably move the discussion from Announce to General.

To support git-style syntax while using Argon, I'd do this:

1. Find the (possibly empty) initial sequence of tokens that start with a dash.  Pass them to an Argon-derived class which we'll call `Stem', which parses them.

2. If no more tokens exist (as in "my-command --help"), do what we can with the options we've seen, and then exit.

3. Otherwise, the next token must be a subcommand name: we've seen something "my-command --verbose display-widgets --paginate".  Use that token to select a leaf class, also derived from Argon.  There's one leaf class per subcommand.

4. Pass the remaining tokens (in this example, just "--paginate") to the selected leaf pass for parsing.  Also pass a reference to Stem, so that the leaf code can use any options garnered by Stem.

It shouldn't be hard to write some reusable code to do this, if it were a common requirement.

On Wednesday, 9 March 2016 at 18:56:10 UTC, Markus Laker wrote:
> On Saturday, 5 March 2016 at 16:28:25 UTC, karabuta wrote:
>> I think he meant: [git status --help], where you have three attributes with the last one being the flag. So in addition to: [status --help] by default, you also have: [git status --help] to get help on status only.
>

> Argon doesn't directly support subcommands.  That probably stems from a bias of mine: that subcommands make it harder for the author to parse the command and to generate good error messages, and also that they make it harder for users to use unfamiliar commands, because users must read a man page that documents eleven things they have no interest in doing just to get to the one thing that they need to do in order to get on with their day.
>  At work, where I have written and I still maintain many hundreds of commands, I've moved away from subcommands completely: every operation gets a command of its own.  But I know that not everyone agrees with me, and that's OK.  If we want to debate this topic further, we should probably move the discussion from Announce to General.

> ......
> It shouldn't be hard to write some reusable code to do this, if it were a common requirement.

I don't like subcommands myself. That's why Linux is such as mess with so much inconsistencies.

On Thursday, 3 March 2016 at 09:33:38 UTC, Johannes Pfau wrote:
> Am Thu, 03 Mar 2016 09:09:38 +0000
> schrieb Markus Laker <markus.laker@gmail.com>:
>
>> * It can open files specified at the command line.  It can do a simplified version of what cat(1) does and many Perl programs so, and open a file specified by the user or fall back to reading from stdin.  There's also a convention that the user can type "-" to mean stdin or stdout, depending on the open-mode you specify.
>
> The rest of this list sounds quite good, but please reconsider automatically opening files: https://media.ccc.de/v/32c3-7130-the_perl_jam_2

No one wants to watch a 40 minute video just to find out what your point is.

>
> I guess the scenario can't happen in D as our open file methods won't execute programs (!) but still....

But still? What other problem is there? What does it matter whether the command line parser opens the file or some other part of the program does?

On Wednesday, 9 March 2016 at 18:56:10 UTC, Markus Laker wrote:
> To support git-style syntax while using Argon, I'd do this:
>
> 1. Find the (possibly empty) initial sequence of tokens that start with a dash.  Pass them to an Argon-derived class which we'll call `Stem', which parses them.
>
> 2. If no more tokens exist (as in "my-command --help"), do what we can with the options we've seen, and then exit.
>
> 3. Otherwise, the next token must be a subcommand name: we've seen something "my-command --verbose display-widgets --paginate".
>  Use that token to select a leaf class, also derived from Argon.  There's one leaf class per subcommand.
>
> 4. Pass the remaining tokens (in this example, just "--paginate") to the selected leaf pass for parsing.  Also pass a reference to Stem, so that the leaf code can use any options garnered by Stem.

It is a wrong way, because switches may have arguments (not starting with a dash).

I am now considering to write a new object-oriented command line parser from scratch because it is sometimes easier to write new code than to understand other's one.

> It shouldn't be hard to write some reusable code to do this, if it were a common requirement.