GetOpt formatting improvements

[Isaac Dupree]

Brandon S. Allbery KF8NH wrote:
> 
> On 2008 Jun 29, at 19:40, Isaac Dupree wrote:
> 
>> maybe these can be resolved somehow without keeping really verbose 
>> documentation: what do other people think?  Are these cases obscure 
>> but nevertheless standard cases of getopt since Unix/GNU history? 
>> (e.g. it seems that compilers behave differently from "normal 
>> programs", behave differently from everyone else's slightly different 
>> implementations of arguments)
> 
> On of the points of getopt is that -fFLAGS and -f FLAGS both work 
> without any extra code.  Standard getopt doesn't do optional arguments 
> at all; GNU getopt handles -vn, -v n, and -v -- or -v -x (for random 
> options -v, -x, the former taking an optional argument; the latter two 
> cases are recognized as argument omitted).

ah-ha, so it is an unpleasant behaviour of ambiguity resolution.  Oh, 
well, I don't know what I want.  But then saying "-v[n]" to me seems a 
little more misleading to say than "-v [n]" although they really mean 
the same thing (what if "-v[n]" makes me think "-v foobar.txt" would 
pass foobar.txt as a positional argument rather than a verbosity 
level?).  Proposal #3 is to just say "-v".  It took me a while to figure 
out how passing arguments to short and long options worked at all (one 
requires the presence of "=", the other requires its absence... again, 
except for exceptions such as ghc), so I might err on the side of being 
more verbose, less obscure.

-Isaac