I've often wished for this.  Also my co-worker Rob just wished for it.

On Feb 3, 2006, at 6:07 PM, Zooko wrote:

>
> New submission from Zooko <zooko@zooko.com>:
>
> I've often wished for this.  Also my co-worker Rob just wished for it.

Could you give an example?  The idea of "splitting a hunk" makes no  
sense to me.

Thanks,
Jason

See also RT #172
http://otherbugs.darcs.net//Ticket/Display.html?id=172

Suppose I fix a bug like this:

-void splodge(int c) {
+void splodge(long c) {

And I also add a new function:

+int blorf() { return s_blorfulocity / s_RAT; }

Then when I run darcs record it will offer me to record this hunk

-void splodge(int c) {
+int blorf() { return s_blorfulocity / s_RAT; }
+
+void splodge(long c) {

I don't want to record that hunk!

What I want is to record those two conceptual changes in two separate patches.

interactive hunk editiing
Import of RT #172 (Merge)

guest <nothingmuch@woobling.org> 2005-01-12
-------------------------------------------
Subject: interactive hunk editiing

Sometimes i edit too much before recording.

I'd like to be able to get a large hunk, and then break it up manually
with my editor.

For example, given

+paragraph
+
+paragraph2

I'd like to be able to muck the diff into something like

__HUNK_BEGIN__
+paragraph
__HUNK__END__
__HUNK__BEGIN__
+paragraph2
__HUNK_END__

and then have darcs generate 3 hunks, one for the first paragraph, one for the
second, and one for the white space in the middle, and splice these into the
queue of patches.

I just want to say that I also would like to have this feature. I wanted several
times in different situations. In my last case I was working in a big refactor
of some piece of code and one function was done and tested. Hours of works I
didn't want to miss. But I don't want to record all, there's a lot of trash
around that function. Even the original code would continue to run if I add this
function maintaining, so it makes sense to just record it.

Oh, it's not just me, then.  Interactive patch editing would be overkill for my
needs, though: I'd be happy with a regex (or something) that caused darcs to
split a hunk whenever it encountered it.  For example, for editing Perl files I
might set it to '^sub ', or for Lisp to '^('.

Would anyone like to propose a specific UI for how we could implement this? 

I have sometimes wanted this myself, but not strongly. I have difficultly
visualizing how this could work in away that feels worth using.

The following is off the top of my head and is a "wish".

Maybe when you are doing "darcs record" and you are looking at a hunk, and you
see that the hunk contains two logically separate changes, you can hit the key
to split the hunk, and then it will show you a new hunk (replacing the one that
you were just looking at) which is the first half of the one that you were just
looking at.

That might be sufficient!

On 07/02/2008, Mark Stosberg <bugs@darcs.net> wrote:
> Would anyone like to propose a specific UI for how we could implement this?

As for interactive hunk editing, here are some thoughts (since you ask
for them).
One principle is that interactive hunk-splitting should be just that
(no actually
modifying the hunks).  I can't justify this principle other than
thinking that it would
just make life simpler for us.

We could rearrange the presentation so that all lines are together, for example
instead of presenting something like

-removed1
-removed2
-removed3
+added1
+added2

We would present the following text to the user.

'Put **HUNK** anywhere you would like to see a hunk boundary.  Change
only the hunk boundaries. Do not modify the hunks themselves, or darcs
record will not understand the changes)

** HUNK **
-removed1
+added1

-removed2
+added2

-removed3

On 07/02/2008, Eric Kow <eric.kow@gmail.com> wrote:
> One principle is that interactive hunk-splitting should be just that
> (no actually
> modifying the hunks).  I can't justify this principle other than
> thinking that it would
> just make life simpler for us.

Come to think of it, maybe I *can* justify this behaviour.  By
enforcing a don't-change-the-hunks rule, we guarantee to the user that
they have not accidentally changed something whilst trying to split a
hunk.  (yeah, we could also flag any changes, but would the user
actually notice?)

Zandr just mentioned that he wished for this feature.  (He wasn't previously
aware of this ticket or of the fact that other people have wished for the same
thing.)

Currently we have two candidate user interfaces for this.  One is that there is
a new interactive command available in the "darcs record" prompt.  The other is
that you can drop into a text editor to configure the hunks how you like before
going on with the record.

I think the former should be attempted first to see if it is sufficient, because
it feels simpler to learn and use than the latter.  My current proposal is as
follows:

Add a command to the 'darcs record' prompt which you get after it displays the
next hunk.  Currently your choices are record, don't record, don't care, skip
the rest of the file, record all of the rest of the file, etc..  Add one more
option: split this hunk into two equal-sized pieces.  If you choose that
command, then now you are no longer looking at the original hunk, you are now
looking at the first half of it, and you are in the exact same mode -- ready to
choose record, don't-record, split-this-hunk-in-two, etc.

My intuition is that this interface, while being extremely simple to learn and
use, would suffice for 90% of the use cases.

Florent (galbolle) has a use case in issue989.  I'm slightly editing it below
for what appear to be typos (foo/bar switching)

For example, say you have added FeatureFoo and FeatureBar to your project.

you get the following changes:
addfile FeatureFoo.hs (1)
hunk FeatureFoo.hs [...](2)
addfile FeatureBar.hs (3)
hunk FeatureBar.hs [...] (4)
hunk Main.hs 42
+ import FeatureFoo
+ import FeatureBar (5)

One would like to record changes 1-2 and the first line of 5 together, and 3 4
and the second line of 5 together. In that case, one needs to manually split 5,
which would be allowed by the 'e' key.

I would personally go for the edit-the-hunk approach, as highlighted by kowey's
copy of my suggestion. (the 'e' key there refers to dropping into an editor for
edeiting the hunk). I don't think splitting at 1/2 of the hunk is going
to be very good (what if the part you want to record is the middle third?).

A nice minimal UI would be to show the hunk in a pager with a cursor. Ask the
user to put the cursor at the patch boundary, get the position of the cursor and
split there. If that pager-with-a-cursor is too hard to implement, just ask for
a line number where to split. (and recurse like in zooko's proposal)

On Aug 12, 2008, at 10:01 AM, Florent Becker wrote:

> I would personally go for the edit-the-hunk approach, as  
> highlighted by kowey's
> copy of my suggestion. (the 'e' key there refers to dropping into  
> an editor for
> edeiting the hunk). I don't think splitting at 1/2 of the hunk is  
> going
> to be very good (what if the part you want to record is the middle  
> third?).

I'm not sure, but I think that in that case it will be quick and easy  
to recurse a few times to select just what you want.

I think this is an empirical question which is best answered by  
trying it and seeing: is the UI where you just have a single key that  
spits in the middle more quick-and-easy or less quick-and-easy than  
one which prompts you for a line number or one which opens an editor?

My guess is the first one, but I wouldn't trust my intuition (or  
yours) about that without experimentation.

Regards,

Zooko

On Aug 12, 2008, at 11:40 AM, Florent Becker wrote:
>>
>> I'm not sure, but I think that in that case it will be quick and  
>> easy to recurse a few times to select just what you want.
>
> I beg to differ: I just experimented by hacking together a couple  
> of emacs functions, and splitting in the middle is painful, not  
> only because of the number of recursion steps (well, that does feel  
> silly, but that is not the point).

Okay, if you've given it a good experiment and you still think it is  
inconvenient, then I hereby respect your intuition about this.  :-)

>  The first frustrating thing is that you have to count to know  
> where the middle is, so at each step you would have to do "p" to  
> see the hunk, hunt the middle and the interesting point in the  
> patch, then actually do the split.

I don't understand why you have to count.  The behavior that I  
envisioned was: "step 1.  Is this hunk that I'm looking at the hunk  
that I want?  If Yes, hit the accept button.  If No, hit the split  
button, then go back to step 1.".

> The second thing is that after the second recursion step, the  
> extract of the hunk which you see becomes quite meaningless.

I don't understand why this happens either.  Could you share your  
emacs functions so I can try it?

> So I would strongly advocate printing the line numbers of the hunk  
> (filewise line numbers, that is), and having the user select one.  
> Is it really hard to ask the user for a number when they have hit a  
> given letter? (genuine question, and if it is, isn't it time to  
> refactor a bit the interactive code?)

My intuition is that entering a line number is a lot more effort than  
the "Yes/No->iterate" behavior that I described above.  But my  
intuition isn't worth anything, because I haven't tried it.

Regards,

Zooko

On Aug 12, 2008, at 11:40 AM, Florent Becker wrote:
>>
>> I'm not sure, but I think that in that case it will be quick and  
>> easy to recurse a few times to select just what you want.
>
> I beg to differ: I just experimented by hacking together a couple  
> of emacs functions, and splitting in the middle is painful, not  
> only because of the number of recursion steps (well, that does feel  
> silly, but that is not the point).

Okay, if you've given it a good experiment and you still think it is  
inconvenient, then I hereby respect your intuition about this.  :-)

>  The first frustrating thing is that you have to count to know  
> where the middle is, so at each step you would have to do "p" to  
> see the hunk, hunt the middle and the interesting point in the  
> patch, then actually do the split.

I don't understand why you have to count.  The behavior that I  
envisioned was: "step 1.  Is this hunk that I'm looking at the hunk  
that I want?  If Yes, hit the accept button.  If No, hit the split  
button, then go back to step 1.".

> The second thing is that after the second recursion step, the  
> extract of the hunk which you see becomes quite meaningless.

I don't understand why this happens either.  Could you share your  
emacs functions so I can try it?

> So I would strongly advocate printing the line numbers of the hunk  
> (filewise line numbers, that is), and having the user select one.  
> Is it really hard to ask the user for a number when they have hit a  
> given letter? (genuine question, and if it is, isn't it time to  
> refactor a bit the interactive code?)

My intuition is that entering a line number is a lot more effort than  
the "Yes/No->iterate" behavior that I described above.  But my  
intuition isn't worth anything, because I haven't tried it.

Regards,

Zooko

Here is the dirty emacs-lisp I used. Note that it cuts at the line that's
closest to the middle of the buffer, not the middle-line, so you have to
experiment on a file with not-too varying line-lengths. I also supposed that you
would do a first run in which you locate the start of your hunk using first-half
and last-half, then go back to the start with C-x n w, cut what's before the
point (this step would be done by darcs), and locate the end of your hunk. If
you actually thought of another UI, feel free to experiment.

After a few further experiments, I see that cutting at the middle can also be
useful. (I had biased the experiment by using long files in which I tried to cut
a small piece near the middle). What I would recommend now is to ask the user
where to cut (at which line), defaulting to the middle, and recurse. This way,
to use bisection, you just keep hitting 's'plit and return alternatively, and to
enter a line number, you enter it once and record thereafter. Ok, make 's'
accept the default place where to cut, and you're set.

(defun half () (interactive)
  (save-excursion
   (goto-char (/ (point-max) 2))
    (move-beginning-of-line 2)
    (point))
)

(defun first-half () (interactive)
   (narrow-to-region (point-min) (half)))

(defun last-half () (interactive)
  (narrow-to-region (half) (point-max)))

"What I would recommend now is to ask the user
where to cut (at which line), defaulting to the middle, and recurse."

Hey, that sounds like it might be the best of both designs.

I propose a preliminary research subtask: find out how git solves this problem
(from a UI standpoint).  They now have interactive commits, and apparently their
interactive commit has a feature like this [tsk, tsk, :-)]

It would be good to have a report on this on the tracker.  Anyone?

This description of git's interactive commit was sent to me by Michał Janeczek a
user of both git and darcs:

==============

"git commit" command records all changes staged for a commit. You
stage a change to commit with the "git add" command. By default,
entire change to a file is recorded. "git add -p" enters interactive
mode, in which user is shown a patch, and has a few options, most
interesting of which are:

's' - split into contiguous hunks, then present user with choices for
them individually. It seems to be just what darcs does by default.
'e' - edit patch in external editor

Using example situation from http://bugs.darcs.net/msg473, the edit
may look as follows:

1) I have a recorded file f.c

void splodge(int c) {
}

2) then I change it into

int blorf() { return s_blorfulocity / s_RAT; }

void splodge(long c) {
}

3) I issue command "git add -p f.c", and choose to edit patch manually
$ git add -p f.c
diff --git a/f.c b/f.c
index a32488e..cf4b43e 100644
--- a/f.c
+++ b/f.c
@@ -1,2 +1,4 @@
-void splodge(int c) {
+int blorf() { return s_blorfulocity / s_RAT; }
+
+void splodge(long c) {
 }
Stage this hunk [y/n/a/d/e/?]? e

4) External editor opens up with this content
# Manual hunk edit mode -- see bottom for a quick guide
@@ -1,2 +1,4 @@
-void splodge(int c) {
+int blorf() { return s_blorfulocity / s_RAT; }
+
+void splodge(long c) {
 }
# ---
# To remove '-' lines, make them ' ' lines (context).
# To remove '+' lines, delete them.
# Lines starting with # will be removed.
#
# If the patch applies cleanly, the edited hunk will immediately be
# marked for staging. If it does not apply cleanly, you will be given
# an opportunity to edit again. If all lines of the hunk are removed,
# then the edit is aborted and the hunk is left unchanged.

5) At this point I may extract just one feature from the patch, either by
removing +blorf() line, or removing "+void splodge" line and changing
"-void splodge" to " void splodge" (as explained by the quick guide)

6) If I produce a bad patch, I am given an option to continue editing it,
or restart:

error: patch failed: f.c:1
error: f.c: patch does not apply
Your edited hunk does not apply. Edit again (saying "no" discards!) [y/n]?

Thanks to Michał Janeczek for the report.

Heh -- you know how git has a wide-spread reputation for having a terrible UI?

You may not know this.  Almost every commentator that I have read, even the ones
who are starry-eyed over git's vast potential and beautiful crypto-dag
structure, agree that its UI is the worst UI of all DVCS.

Anyway, it is a good data point to know how this feature works in git.  Thanks.

Hi. Do people feel that being able to split a hunk along empty lines would be 
sufficient? See also issue1174 -- I tend to think that majority of usecases for 
hunk-splitting would be covered by such a functionality: Hit 'b' (as breakup) 
and you get presented with a single hunk per paragraph of the current hunk. 
Remaining hunks are again presented unaffected. The other possibility would be 
to make paragraph breakups default when recording and avoid new interactive 
commands altogether. The only downside is that you'd have to hit f instead of y 
on file imports and you'd get a few more hunks in certain records.

No -- the use case that I have wanted, and that several other people have
mentioned to me -- is to split a source code hunk into two logical parts even
though there isn't a blank line between those parts.

P.S.  I believe git has a way to do this by dropping you into an editor and
letting you mark up the patch in some way and then returning to git.  I think an
interactive mode would be more darcslike and better.  Here's another idea for an
interactive mode: just offer each line in turn and let the user hit "y" or "d"
for each line.

Zooko, it might help to provide some concrete examples. There is the one by 
Kowey, but others might help establish some pattern that's not completely 
obvious (although I doubt it). Also, it might help us asses how much of the 
cases would be solved by paragraph splits. At least one person I know said 
basically all of their splitting is on empty lines. I personally need splitting 
very rarely, and the most cases I recall were of the paragraph variety as well.

One possibility is to provide a 'b' command that shows you the hunk with line 
numbers in it and lets you break up the hunk on a given line, on all empty 
lines or on a regexp. It is yet another interface to learn, but possibly still 
easier for the common case than a text editor?

> One possibility is to provide a 'b' command that shows you the hunk with line 
> numbers in it and lets you break up the hunk on a given line, on all empty 
> lines or on a regexp. It is yet another interface to learn, but possibly still 
> easier for the common case than a text editor?

My leaning would to be continue to study the use cases more (as Petr suggests) and
choose one method of splitting to move forward with for now. It could very well be
that one simple method of splitting is good enough, and having three options for it
would add unecessary complexity.

    Mark

If I understand correctly, Ganesh is work on this, so I'm assigning to him.

Some related bugs:
 * issue291  - edit file being recorded during record time
 * issue1174 - common use case of being able to break hunks up by whitespace
 * issue126  - [this bug] split hunk boundaries

I'm also tacking on the Git tag :-P because this is something Git can do that we
can't.  Of course we should aim to be better than Git by having a well
thought-out user interface that you don't have to "learn", just use.

This is a special case of issue291 so marking as duplicate and copying nosy.