[darcs-users] Feedback on hunk splitting with Darcs 2.4 beta 1

Jason Dagit dagit at codersbase.com
Sat Jan 16 08:16:39 UTC 2010

On Fri, Jan 15, 2010 at 10:30 PM, Eric Kow <kowey at darcs.net> wrote:

> Hi Mark,
> On Fri, Jan 15, 2010 at 21:10:59 -0500, Mark Stosberg wrote:
> > I was interested to try the hunk splitting sometimes because I've wanted
> that
> > feature myself at times. My first impression found it to be a frustrating
> and
> > unintuitive experience. I'll try to explain why.
> Thanks very much for the feedback!  This is what I've been hoping to get
> when the hunk splitting first came online.
> > Here's a "screenshot" of what it looked like for me:
> >
> > ####################
> > Interactive hunk edit:
> >  - Edit the first set of lines to insert a new change before the current
> one.
> >  - Edit the second set of lines to insert a new change after the current
> one.
> > ===
> > ===
> >         use Data::Dumper;
> >         warn Dumper ('foo!');
> > ===
> >
> > #####################
> >
> > First, it's not clear what "set of lines" refer to. Is it referring to
> the
> > "===" lines? I wouldn't call those sets. Maybe it is referring to the
> content between
> > the === lines. But there nothing between the first two === lines, so
> referring to nothing
> > as a "set of lines" is also confusing.
> There's two issues here.  First, the separators are not well named.
> This can be addressed by some variant of http://bugs.darcs.net/patch123
> Second, and this is not readily apparent.  The hunk editor is very
> simple and powerful in the usual Darcs style.  The only problem is that
> this is a lot less intuitive than the rest of Darcs.
> Once you have a sort of working mental model of it, though (eg. through
> trial and error), it's really powerful and easy to use.
> The problem is that getting people over that initial hurdle!  (We're
> even contemplating hiding it for this release, which would be a little
> sad, but better than giving people a bad first impression).
> I'm going to try and do this now if you and Isaac will bear with me
> (with Ganesh correcting me if I say something stupid).  Perhaps in light
> of my explanation you'd be willing to offer up a solution?
> Here are the ideas:
> 1. The hunk editor turns your hunk patch into a sequence of hunk patches
> 2. Any empty patch in that sequence is filtered out.
> 3. You can make arbitrary edits in the hunk editor.  One example use of
>   this would be to clean up trailing whitespace on the spot.
> 4. Here's the wild and crazy part: the sequence of patches created by
>   the hunk editor is COMPLETELY EQUIVALENT to the original patch.
>   This means you can pop out the original patch, slip the sequence in
>   and Darcs would be none the wiser. Huh?  How's that possible?...
> 5. The trick behind is that Darcs actually splits the patch into a
>   sequence of three (or more) patches.  For now, I'll ignore the
>   (or more) case and focus on the basic idea.
>   The point is that you can think of the hunk editor as manipulating
>   a sequence
>     pb p1 pa
>   When you fire up the hunk editor, pb and pa are empty and p1 is your
>   original hunk.  In the editor, what you are doing is making arbitrary
>   edits to p1 (both to the before and after sections).
>   When you are satisfied with your edits, darcs automatically infers
>   what pb and pa have to be in order to make the sequence equivalent to
>   the original hunk. (NB: You may not always see pa and/or pb because
>   in #2, empty hunks get filtered out.)
>   Got that?  The more general explanation is that you are actually
>   editing the sequence
>     pb p1..pN pa
>    Which you will only see if you use blank lines to break up blocks
>    of text (like in regular Darcs usage).
> I realise this sounds like wild and crazy over-excited talk for people
> who just want to split some hunks, that I'm throwing a bunch of mumbo
> jumbo out in response to what looks like a simple thing... but please
> bear with me!
> http://wiki.darcs.net/HunkEditor tries to document some of the
> implications of #1-#5, but it's poorly written, for which I apologise.
> I should say that I really hated the hunk editor UI when I first
> encountered it, but then I started using it (a lot) and now I think it's
> great!  It turns out to be very easy/convenient once you've internalised
> that chunk of mental model.  I would definitely be very open to change
> (and I'm sure Ganesh would as well), but it would be awesome if we could
> somehow preserve this simplicity/power.
> We keep thinking the right explanation is just around the corner...
> One idea I had was to change the UI to look like this...
> ####################
> Interactive hunk edit:
>  - Changes outside of the EDIT regions will be ignored
> some lines removed
> some other lines removed
> === BEFORE PATCH 1 (EDIT BELOW) =======================================
> some lines removed
> some other lines removed
> some lines added
> some lines added
> === AFTER PATCH 2 (EDIT ABOVE) =======================================
> some lines added
> some lines added
> ===
> #####################
> The hope is that (with a tiny bit of text), this would make it more
> explicit what's going on, that you can think of it as editing a sequence
> of patches by manipulating the before and after states (but that you
> can't touch the first and last bit of that sequence).  On the other
> hand, this gets very awkward when the patch is large :-(
> Argh! We need somebody who can think about user interfaces!

I haven't looked at the hunk editing interface until I saw this thread.  I'm
rather confused by it (I just spent a bit reading the tutorial on the wiki

Some input about finding the UI design.  I think this is likely to be a case
where this feature needs to be quick/convenient and easy to understand
relative to quitting darcs, editing the file, and starting to record again.

I base this on things I've learned about human computer interaction.  It
seems that humans don't always "optimize" for the most logical behavior.  We
frequently go for things that require less overall effort.  Learning and
understanding a new way of doing things is often a lot of effort.  Sometimes
after the learning the familiar task can be done in a new way that requires
less total effort.  Even so, we seem likely to often avoid the learning

It might sound like I'm damning this feature, which is not my goal, I think
this feature is very needed because it can actually provide functionality
you can't get from editing alone.  I think this implies that some aspects of
being easier to use are already there.  I think once you understand how to
use it, it's likely to be quicker/more convenient too.  Thus, I think the
missing component is in the understanding.  The feedback I've seen in this
thread also seems to indicate this.  It also seems Eric/Ganesh are already
aware of that issue.

Some ideas on improving it (sorry if these were already suggested, tried, or
  a) What about removing the '===' markers and using the same presentation
that hunk patches use?  Meaning, unchanged lines begin with a space, removed
lines begin with -, and added lines begin with +.  What I'm trying to
achieve is that darcs has already trained people to recognize a particular
format for hunks.  Let's try to reuse what the user has already learned.
 Hopefully less learning means less effort to reach understanding.

  b) Provide more feedback about the implied before/after patches.  I'm
still struggling to see why these are a good thing.  For someone trying to
predict what will happen they certainly seem to make the predictions more
difficult.  Here I want to reduce uncertainties and reduce the need to
develop new intuitions.  I have to admit, I don't know what to concretely do
to improve the feedback, instead I merely have a hunch that improving it is
likely to help.

Eric's last example UI might address (b) but I think I'm not understanding
it due to the choice of filler text.  There also may need to be some
iteration as the implied patches update as user edits.  Is there some rule
we can use to describe how those patches are implied?  I see mention of
replacing like with like, but I need to see examples of how this affects the
implied patches.

One thing that really confuses me in the example on the wiki (section
"Splitting a block of added text"), is that the line reading "anecdotal
antelope" appears in a patch at all.  The reason it surprises me is because
that line was removed from the input (it doesn't appear in the "AFTER"

In the section "Splitting a block of removed text", I think this UI would
make more sense to me:

BEFORE                      AFTER
==                          ==
-rambling robot             -rambling robot
-red rover                  ==
==                          +red rover

Here I'm using == to separate patches in a sequence and using +/- to show
when lines should be added/removed in a given patch. I haven't thought about
if this UI is feasible to implement from a mechanical point of view.

I hope my ramblings are of some use.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20100116/8520db0c/attachment-0001.htm>

More information about the darcs-users mailing list