[darcs-users] GNU Emacs frontend: which one ?

[Jonathan]

On Fri, 10 Jun 2005 Joe Edmonds <joe at elem.com> wrote: 

> I like Juliusz' version of vc-darcs (a back end for the more-generic
> "vc" package).  It supports "C-x v =" to ediff the current buffer
> with its _darcs/current/ version.  You can get it here:

I like the functionality that vc-darcs provides, but it hits darcs'
performance problems for me.  I believe the issue is that vc triggers
to check the current status and history as soon as a file within a
repository is opened.  Not too bad when you're working in ~/bin and
it's a separate repo, but with 10MB of /etc under darcs it means an
extra 17 second delay with a hot cache for darcs and the file on a
1.6GHz Pentium M.  That's painful enough as it is, but you take the
hit for _every_ file you open.  It looks like it's entirely a bad
interaction with vc itself, but it makes vc-darcs unusable for me.

> An ediff of an entire patch is an interesting idea.  I envision:
> open a darcs patch in emacs, press "n" to advance through the hunks
> of the patch (not sure what to do about non-hunk patches).  If the
> current hunk is in a different file from the previous hunk, create
> new buffers to display the ediff for that file.

I think that would work well, or perhaps a mode more like native
ediff: buffer A is pre-patch (or working copy), buffer B post-patch,
use the normal ediff navigation but hook into darcs for hunk-handling.
One option that might be interesting is that the ediff results are
applied to the working copy and if you didn't apply the full patch you
can then create a new one.  This could be useful for conflict
resolution and handling submitted patches that you want to cherry-pick
portions of.  Step through, take the parts you want, use ediff to mark
the conflicts & edit them, record a new patch with the original commit
message and a note with what changes you made to the patch.


-- 
Jonathan Conway                                                rise at knavery.net