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