Redesigh of the VC front end

[Eric S. Raymond]

This is a design proposal which I'm posting for comment and critique.

Some months ago I rewrote the vc.el backends because the the API to
them needed a rethink in order to handle multi-file changeset commmits.
More recently, it has become evident that the front end's interface design
needs a rethink as well.  While it works with multi-file changeset commits,
there has been no clean way to specify an operation on a directory or an 
entire repo.  Instead, vc-deduce-fileset has had a tricky set of rules that
expanded directories into directory file lists in certain special cases.

Presently the rules work like this:

1. If we're in a VC-dired or VC-dir buffer and a nonempty fileset
has been marked, return that fileset.

2. Otherwise, if you are in a vc dired buffer, and
include-files-not-directories is non-nil, and no fileset is selected,
select all files at and below directory level.

3. Otherwise, if we're in a buffer visiting a version-controlled file, the
selection set is a singleton containing that file.

4. Otherwise, if we're visiting a change-comment or log buffer, the
fileset is the one associated with its parent buffer

5. Otherwise, if allow-directory-wildcard is on-nil, and you're in a 
dired directory, select all files below the current directory

6. Otherwise, if we're allowing selection of unregistered files and
the current buffer is visiting one, return that singleton set.

Stefan Monnier thinks rule 5 is a misfeature and he's got a point.
Rule 2 is a misfeature for similar reasons; they're both ways to get
around the fact that directories aren't really first-class in Dired
and cannot be passed back to a Dired client (the client gets all of
their files as part of the merked set, instead).

More generally, these rules are messy and complicated.  They have a
functional gap as well; there is no way at all to designate a selection that
says "I don't care where we are, operate on the entire repo", which is 
an important concept when doing (say) commits or log-print requests on
any VCS from Subversion onwards.

Neither of these problems (selecting directories or selecting the
whole repo) can be solved as long as the VC interface is tied to
Dired.  Dired is just too file-oriented.  Fortunately, Dan Nicolaescu
and Stefan Monnier have written much of a dired-like browser front end
using ewoc.  The ewoc code is flexible enough to allow us to select 
directories as filesets, though it is presently being used only
as a sort of Dired emulation.

So the Dired code has to go, once the vc-dir code is at functional
parity to it.  This will take a little more work.

Here are the new rules I propose to implement:

1. If we're in a vc-dir buffer and a nonempty fileset
has been marked, return that fileset.  A fileset may include marked
directories.

2. When the backend supports the concept, every vc-dir buffer has a
special top-line entry that can be marked to select the entire repo.

3. If we're in a buffer visiting a version-controlled file, the
selection set is a singleton containing that file.

I plan to get rid of include-files-not-directories and
allow-directory-wildcard and pass directory names to the backends when
that's what the user selected.  This means that file-oriented back ends
(SCCS, RCS, CVS) will have to do directory expansion for themselves
when it is needed.

There is also a bit of murk around the handling of unregistered files.
I haven't completely thought that one out yet.  I think the code can be
rewritten so that filesets of unregistered files are simply passed to
the back end, yielding the VCS's own error for this case when the user
did not select 'register' as the operation.

Finally, anyone interested in working on or just undertstanding this code
should note that I have split vc.el in half.  The interface logic now lives
in vc-dispatcher.el, which knows all about the VC user interface and (almost)
nothing about VCSes or back ends.  This code could be used for other things,
like implementing a Midnight-Commander-style file manager.  (By the time
I'm done, I expect to be able to remove that "(almost)".)

One goal in doing this was to reduce the global complexity of
vc.el. That has been achieved; the interface between them is very
narrow and well-defined, consisting only about 6 functions.  Just as
importantly, I did this in order to separate in my own mind the UI
issues from the VCS logic.

Barring more weirdness like the gastritis thing that put me in the 
hospital yesterday, I expect to get all this done within the next two weeks.
I have put a temporary hold on my other projects to concentrate on it.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

A man who has nothing which he is willing to fight for, nothing 
which he cares about more than he does about his personal safety, 
is a miserable creature who has no chance of being free, unless made 
and kept so by the exertions of better men than himself. 
        -- John Stuart Mill, writing on the U.S. Civil War in 1862