Editable diffs in FilePatchItems

[smashwilson]

Once #1712 lands, the FilePatchItem will be rendering diffs with an Atom TextEditor component, but it will be in read-only mode. Let's let users edit diffs directly from the diff view! This saves you the trouble of needing to toggle to an editor and back again when you notice typos, console.log() statements, or .only() tests when reviewing unstaged or staged changes.

Editing a diff's contents should mark the item as "modified" and be treated by Atom like an unsaved text editor: it should cancel shutdown with a prompt to save and so on. Saving the item should apply the modifications to the underlying resource.

Saving edits to a diff within an "Unstaged changes" file patch item modifies the underlying file in your working copy, as though you'd pressed cmd-O and edited the file there.

Saving edits to a diff within a "Staged changes" file patch item modifies the staged index entry for this file. This leaves the file on disk unchanged, but the saved modifications will be applied to the file that ultimately becomes a part of the next commit.

Editing addition or unchanged lines is straightforward: the edits are written through to the equivalent locations in the "new" file. When editing a removal, though, the removed line needs to "split" into an addition and a removal with the edit and the cursor placed on the addition line.

[smashwilson]

I'd like to make it really clear somehow:

• When you can and cannot edit the diff that you're looking at
• If you do edit the diff, what will actually be changed when you save your edits

@simurai, do you have any thoughts about how we can accomplish this? Maybe we could add some kind of badge or flair to the patch header with some kind of pen icon when it's writeable, and some text describing the edit destination?

[smashwilson]

Another consideration: when you're editing a diff that will be applied to a file in your working copy, we should update the underlying TextBuffer immediately, to update any other TextEditors that have that file open. This lets us stay consistent with the behavior when you have multiple TextEditors open on the same file. That also means we'll have to clean up after ourselves if the user closes the modified FilePatchItem and discards their changes.

This gets extra fun once we tackle #1689 and could have to modify different TextBuffers depending on the locations of specific edits 🙃

[simurai]

Maybe we could add some kind of badge or flair to the patch header with some kind of pen icon when it's writeable, and some text describing the edit destination?

Yeah, some sort of read-only badge would be great. Hovering could show a tooltip with the reason?

In VS Code, the cursor (caret) doesn't blink and if you start typing, a tooltip appears:

Or we could not show the cursor at all and show the default mouse cursor (cursor: default;). It's still possible to select for copying or staging/unstaging: