This has probably been the case since the very beginning. I propose to
re-think this choice.
First, using -i and --xml together can make good sense. For instance, I
have often wanted to do "darcs changes -i --xml", so I can view all the
patch meta-data (including the hash), but still one-by-one, i.e.
interactively. This is not possible now and for no good reason I can
think of.
Second, I think that generally options should be either mutually
exclusive (and then darcs should fail with an error message complaining
about conflicting options) or else mutually independent (orthogonal), so
we can freely combine them. This makes the whole user experience more
predictable. Deviating from this principle might be necessary in some
exceptional cases, e.g. for compatibility, so this should be understood
as a guide line, rather than a strict rule. Still, I think it applies in
the case of --xml vs. -i.
Strictly speaking, making --xml and -i respect each other would be an
incompatible UI change, but I guess the number of usages that would
actually break because of this is minimal. Currently, if I specify -i
and --xml together, the --xml option simply gets ignored. (BTW, this
happens even if --interactive is only specified in a defaults file, but
this is a different issue and will be fixed once my new options system
is in effect.) I guess that few applications rely on that behavior, that
is, use -i to cancel a --xml option.
If my proposal for replacing --xml with --json gets accepted
(issue2397), it would make even more sense to mix it with -i: the --json
output could easily be rendered in a properly indented, human readable
fashion.
|
