This is obviously work in progress. The main thing missing is the ability to
to manually resolve conflicts using a text editor; and more generally, to
edit prims directly. The former will supersede the 'inject' action which can
then be removed. Nevertheless, it is already quite useful as-is, so I am
screening it.

2 patches for repository http://darcs.net/screened:

patch 46d9b47fd80c5c981a7f1a064479cd6ec5303a09
Author: Ben Franksen <ben.franksen@online.de>
Date:   Thu Jun 30 23:38:10 CEST 2022
  * new command: rebase edit

  It allows interactive editing of suspended patches. We navigate through the
  suspended patches and offer the actions: (o)bliterate (dissolve into fixups,
  like rebase obliterate), (s)quash (with previous suspended patch), (i)nject
  (like rebase inject), (e)edit name and long comment, together with the usual
  viewing commands, as well as (q)uit, and (d)one.

  In contrast to other interactive commands, this one performs the requested
  actions immediately (in memory), instead of first selecting patches and then
  doing the action for all of them in a batch. This allows us to circumvent
  limitations arising from dependencies, since patch selection requires that
  selected patches can be commuted to either end of the input sequence. This
  means 'rebase edit' also serves as an improved version of both 'rebase
  obliterate' and 'rebase inject'.

patch 5a7336538b2d600d5424fe03b2c8ed6fd25ea8c0
Author: Ben Franksen <ben.franksen@online.de>
Date:   Sat Jul  2 22:14:47 CEST 2022
  * rebase edit: now with undo/redo

Attachments

• new-command_-rebase-edit.dpatch
• patch-preview.txt

I'm not quite sure how to review this sensibly, as it's a 
fairly big new feature.

Maybe the best thing would be to do a final review of the 
feature later on, once it's more fleshed out? My big high-level 
question would be what it adds over potentially simpler 
alternatives, like using suspend and unsuspend to move patches 
in and out of the rebase state and then operating on them at 
the normal repository head.

Shorter-term thoughts:

Maybe it should be a hidden command for now?

I think breaking up Darcs.UI.Commands.Rebase is long overdue,
I should probably have done it when I first wrote it. Perhaps
edit can live in Darcs.UI.Commands.Rebase.Edit as a starting
point?

I'd like to see some doc comments on Edit and EditState.
I guess index/count are just a cache of the length of
the first element and the total lengths? Is eState the old or
new state or something else?

Squash favours the name of the second patch (I think?) -
sometimes I'd like it to use the name of the first one.
(This is also a flaw with doing squash by unsuspending to
the patches to be squashed, then doing an unrecord and
amend-record - it favours the name of the first patch.)

The code looks generally fine though, I'm going to accept
this and those can all be followups (or not). It might be best
to discuss the general points about the feature on darcs-devel 
directly rather than in specific patches.