feature: add option to edit the right side of the diff

[martinvonz]

Description of the bug

Sometimes the changes/lines you want to select are not exactly a subset of the overall changes/lines.

Expected behavior

Have an option to edit the full content on the right side of the diff

Actual behavior

No such option

Version of rustc

No response

[arxanas]

To provide additional context, this is one of the most popular feature requests, and it's one of the main missing features compared to the git add --patch workflow.

Some complications for the implementer:

• The data model currently doesn't support it.
  • At present, the data model is basically a list of lines, some of which have checkboxes. See Section.
  • We'd have to add support for an arbitrary edits/hunks.
  • Or, the caller would have to transform the user edits into the scm-record data model, which is probably non-trivial (although scm-record could provide some helper/example functions to do so).
• The intended design of scm-record is that it's primarily meant to be a "dumb" UI for the provided data.
  • Depending on the design for this feature, we'd potentially have to calculate a diff as part of editing the hunk. Currently, the UI doesn't do — and isn't intended to do — any diffing by itself.
  • In the most recent version of scm-record, the UI is able to call into RecordInput to launch the commit message editor. We could add more functionality to that trait to support external hunk editing.
• The data model currently doesn't support a principled way of preserving the "identity" of individual elements.
  • Currently, all addressing is internal and via relative offsets/identifiers, such as "file 3, section 2, line 1". This system may need to be rethought if new files/sections/lines can appear as part of normal editing.
  • There's currently an invariant that the input structure is the same as the output structure, but with the commit message and some booleans potentially modified. If the structure of the data changes, then the caller can also no longer use e.g. Vec indexes to address a certain file.
  • [tangential] This is probably relevant for implementing multi-way splits as well (for example, in jj, you would want to know which side of the commit should preserve the change ID, if any).
• In principle, selecting or unselecting individual lines means that the caller can do better merging via interleaved deltas/weaves.
  • Allowing the user to make arbitrary edits might sacrifice this guarantee.
  • It would be good to support multi-way splits (feature: multi-way splits #73). We'd want to be careful that a prospective design could handle multi-way splits, ideally without inducing conflicts.
  • [additional context] See the Sapling documentation on their version of interleaved deltas.