On Thu, 08 Aug 2013 10:58:58 +0200, Stephan Beal <sgb...@googlemail.com>
wrote:
On Thu, Aug 8, 2013 at 10:47 AM, Rene <renew...@xs4all.nl> wrote:
-R seems redundant.
It's not _entirely_ redundant - in some cases it changes how the
arguments
are processed. Yes, there are inconsistencies there, but some of the
argument handling relies on one or the other approach. When the app looks
for a CLI flag, e.g. -R, fossil actually removes that flag and its
argument
from the global argument list, which changes the argument count, and many
of the commands use logic like if(g.argc==3){...}, so there non-obvious
side effects when changing whether a command expects -R or not. It the
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
and when not. I'm sure there are reasons why it is the way it is. but I at
least
would consider it a relevant step forward if the CLI would be made more
consistent.
by and then I have "complained" about this in the past already.
e.g, the mixing of
-c
--c
-word
--word
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'.
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?
overall, for some people I'm sure these sort of things are not less
important than a nice GUI. ;-)
j.
now. e.g. a clone implies a -R (but normally in the form of a URL), and
doesn't need a flag. The commands you listed where -R is optional almost
always derive their repo db from the current checkout (which is why -R is
not required). i'm not sure why ui/server don't require -R, but instead
take their repo filename as a non-flag argument. Historical in nature, i
guess.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
