It would be nice to be able to manually edit the hunks when recording.

That is, when using darcs record, be able to hit 'e' for edit after each hunk,
and have $EDITOR open with the current hunk. Modify it, save, and darcs record
records that hunk and goes on with the following changes.

Use case:

This would be especially useful when darcs' diff algorithm yields hunks that are
too big. This is most susceptible to be needed when editing include lists. 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 FeatureFoo.hs (3)
hunk FeatureFoo.hs [...] (4)
hunk Main.hs 42
+ import FeatureFoo
+ imoport 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.

Bonjour Florent,

This is something that others have asked for.  It does sound like an interesting
feature.  Adding you to issue291

I don't think this is a duplicate of 291, since what I propose to be able to
edit is the hunk itself, not the file. I guess the two are close but
not-quite-identical, and they conflict for the use of the 'e' key in record's ui.

While I agree that editing the file could be more intuitive, editing the hunk
allows one some more tricks such as hunk-splitting. Moreover, editing the file
can already be done via amend-record, but not editing the hunk. Last, editing
the hunk would not change the working directory, while editing the file would
change it, so they have different use-cases.

Aside: I'm not sure about the etiquette for requesting de-duplication of bugs,
but I feel this is different of issue 291. Should I comment on bug 291,
de-duplicate, or continue the discussion here while keeping a link ?

Nicely argued!  But now I think it's a duplicate of yet another bug (which I
think you just spotted)

As for etiquette, I would like to encourage a culture of boldness on the bug
tracker.  For example, here, you very clearly and politely argued for the
de-duplication, so I doubt anybody would have been annoyed if you had just
flipped the status to something else.

Argh, I just realised that I gave you a completely useless etiquette answer. 
I'm not sure what the best approach would have been.  I think replying to the
current bug regarding the de-duplication made sense.