Re: Command-line Parsing Preferences

[cblake]

It really shouldn't _need_ to break anything, though mistakes can always be 
made in some initial pass. 

I would think you might also like long option key normalization so that one 
doesn't have to remember when typing commands `--how-toSpell_OptKeys-exactly`. 
Entering commands is often more ad hoc and personal than writing code, to the 
extent they are even distinct.

Also, if it matters, I'm happy to donate 
[parseopt3.nim](https://github.com/c-blake/cligen/blob/master/parseopt3.nim) to 
the cause. That adds a few more features beyond optional symbols like 
"\--"/`stopWords`, and `optionNormalize`. It should be API/backward compatible 
by default, but I really haven't tested it much outside being driven by 
[cligen](https://github.com/c-blake/cligen) macros. E.g., I'm not sure how it 
fares against quoting issues that arose recently.

Re: Command-line Parsing Preferences

[Araq]

> To me this kind of optional symbol table seems both backward compatible and 
> forward looking and strikes a good balance for a stdlib.

I have to admit, this is quite convincing.  Especially since it's just an 
addition to parseopt, breaking nothing, I hope.

Re: Command-line Parsing Preferences

[twetzel59]

cligen looks very cool, I'll need to look into it.

I'm also curious how other people feel about the args situation. In my personal 
projects I've been using parseopt and having a user type ":" like the Nim 
Compiler...

Command-line Parsing Preferences

[cblake]

So, there have been various on again/off again conversations on github about 
how the stdlib parseopt could/should behave. Those conversations seemed to have 
a pretty narrow audience..basically participants on these github issue threads:
[4620](https://github.com/nim-lang/Nim/issues/4620) 
[6818](https://github.com/nim-lang/Nim/issues/6818) .

It made sense to me to raise this topic in the forum where a wider audience 
might weigh in before 0.18/1.0/whatever stabilizing might happen.

The basic issue is whether command users have to separate option keys from 
option values (e.g. with a ':' as the current code does). In order to avoid 
that requirement, command authors need to update a list of option keys whenever 
they change them which is a hassle. So, there is a tension between convenience 
to CLI authors and CLI users. As a user, I often forget to type the ':' and 
would be delighted if more people chose the symbol table route.

Myself, I think having an **optional** symbol table is the most programmer and 
user-friendly solution. That 's what I did in parseopt3 in 
[cligen](https://github.com/c-blake/cligen). If the programmer wants to provide 
more POSIX-like command syntax then that's easy. OTOH, if like Araq they very 
understandably prefer not to have to update a symbol table when they add new 
option keys then they can just ignore that feature and make their users provide 
a ':' to separate option keys and option values. To me this kind of optional 
symbol table seems both backward compatible and forward looking and strikes a 
good balance for a stdlib.

I'm just one person, though, and that's just my opinion. The point of this 
thread is to solicit other opinions/perspectives/input to help figure out the 
best resolution of [6818](https://github.com/nim-lang/Nim/issues/6818) .