Are the changes to Darcs.Repository.Identify related to the --list-
options fix? They look like good things anyway, we have far too many
catchalls in the darcs code and they tend to produce confusing error
messages for users.
> Ganesh Sittampalam <firstname.lastname@example.org> added the comment:
> Are the changes to Darcs.Repository.Identify related to the --list-
> options fix?
At least in part, see below. The problem was, if you said e.g. 'darcs
whatsnew <TAB>' and you are not inside a repo, you'd get an error
message instead of no (empty) completion, messing up your command line.
This is because the commandPrereq stuff (mostly implemented in
Darcs.Repository.Identify) is now done before evaluating --list-options
option, which is necessary in order to get the repo dir, which in turn
is needed to provide the correct fixing of subpaths for the completions.
> They look like good things anyway, we have far too many
> catchalls in the darcs code and they tend to produce confusing error
> messages for users.
Yes. As usual, some factoring of the code was necesary for me to
understand what it does in the first place, so there might be some
changes I made that are not strictly necessary to achieve what I
intended. I hope the code is now easier to understand.
There remain things that are rather non-obvious. For instance,
internally the Repository code seems to assume that the repo location is
either ".", meaning we are acting on a local repo, or else is a remote
location ("URL"). Half-hearted attempts to structure this were made at
some point using the WorkRepo type. However, there are two problems with
it: (1) it isn't used systematically inside Darcs.Repository, but mostly
inside Darcs.UI, and (2) which alternative is used depends on the option
(--repo vs. --repodir), not on parsing the passed string, which is not
very reliable. I have made some progress to clean this particular mess
up but it's not yet ready for screened.