On Thu, Aug 8, 2013 at 11:55 AM, j. van den hoff <[email protected]>wrote:
> On Thu, 08 Aug 2013 10:58:58 +0200, Stephan Beal <[email protected]> > wrote: > >> context of libfossil, that's been one of the minor points on the list of >> things to consider, and while i don't much care for inconsistency in >> software, i _think_ that i'll end up doing it similar to how it is done >> > > just my 2c: I _do_ care for inconsistencies in the CL user interface and > the > -R thing is one of them: I always can only partly remember when it's > required > Sorry for the confusion: "don't much care for" is another way of saying "do not like," and we agree completely that these inconsistencies are not ideal. > e.g, the mixing of > -c > --c > -word > --word > Fossil has always treated the number of leading dashes as irrelevant, so the only inconsistency here is cosmetic (e.g. in the help text). > style options was/partly is another issue. I would argue for reducing it > to -c and --word, probably, which would > also allow to tolerate omission of the blank between short option letter > and its argument > as in fossil diff -r1234 (just like with most unix commands). I've just > checked: it seems (is this true?) that this > "problem" is now only present with `fossil help' where in fact you have > `--c' and `-word' type options > while otherwise it seems to be already `-c' and `--word'. > There are at least 3 or 4 common conventions for how to "properly" structure CLI arguments and Richard chose the one we have now way back in 2007. We could argue about the benefits of other approaches until the end of time but it won't make one approach any more or less correct than the next :/. The current argument parsing code is effectively set in stone - we cannot significantly change how it behaves without taking a risk of breaking CLI commands (possibly with bugs which only show up when certain args are or are not passed in because each flag we check can literally change the structure of the argv array). So... to agree with you: yes, it's unfortunate. But.. IMO it's not bad enough that reworking it is worth the effort and risk involved. Side note: Fossil is not alone in this regard: try using the Sun Cluster 3.0 tools and see if you can figure out why -j is the pneumonic for "resource". > a further small issue is that > on the one hand fossil has the necessary logic to accept unique partial > matches of commands > (e.g. `fossil info' vs. `fossil inf' (both OK) vs `fossil in' (ambiguous)) > but apparently > none to do the same for long options. could the partial match logic not be > extended to long options? > The reason fossil can do partial matches on commands is because the list of commands gets pre-processed and added to a sorted list at build time, which the command dispatcher uses to find commands and close text matches. The CLI options do not, so fossil has no basis for being able to say "-xy might actually be -xyz." You may notice that some programs fail if given an argument they don't understand: myapp --unknown-flag fatal: unknown option: --unknown-flag whereas fossil, due to its more free-form nature, takes the opposite approach - it will accept any options and may or may not use them (which can of course make it difficult to spot your error if you make a small typing mistake: fossil timeline --l1mit 3). Whether not this is the optimal approach is a philosophical question i can't answer (but it is generally the approach my apps use because it's much easier to program and extend). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
