Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Render file patches with a decorated Editor #1512
Use decorations within an Atom TextEditor element to implement a file patch item. This should get us improved performance for large diffs, editable diff support, and open the path for multi-file diff views like a commit or pull request pane.
Just to set proper expectations, I'll likely need to pause and resume this a few times before it lands. Don't worry, I won't forget about it
Concurrent with review
Fixes #1502. ...Eventually
referenced this pull request
Jul 24, 2018
added this to In Progress 🔧
in Feature Sprint : 27 August - 14 September 2018 : v0.20.0
Aug 14, 2018
I'd like to hear your opinion about how selections should work here. Because we're using a proper Atom text editor for the patch body, we have two sets of selection ranges to manage:
At the moment, these are managed independently. The editor selections are manipulated with standard mouse and keyboard actions in the editor itself, while the FilePatchSelection is manipulated by mouse actions on the line number gutters or by clicking on the hunk headers. I've been thinking that this is a bit awkward and counter-intuitive, though.
What I'd like to implement is binding the two together. When the editor selections are changed, make the FilePatchSelection be the set of changed buffer rows that the editor selections currently span, and when the FilePatchSelection is changed directly, set the editor selection to be the corresponding rows.
Can you think of any reason to keep the two independent? Do you think that unifying them would feel natural?
@smashwilson I support this change to unifying handling of editor selections and file patch selections.
I can't speak for other users, but I think I would find it confusing/frustrating to have file patch selections work differently.
We should look at how vscode handles this as well. I believe that you can edit diffs and select text the same way as you select text in the editor, so keeping things consistent here seems like a win.
Would the unifying be that selections behave just like in current buffers, but with the addition that you can click the hunk header to select the whole hunk at once? I think that's a good idea.
When selecting only a single word and then clicking on "Stage Selection", it might feel unexpected that it staged the entire line/row. But should still be better than "forcing" people to only use the gutter to select individual lines for staging.
Thanks for weighing in
We could change the button caption to "Stage Lines" or "Stage Selected Lines. We could also style the selected rows differently to highlight them as "the selected ones" rather than just using the gutter highlight, to emphasize that "the stuff that's this color is what will be applied if you click the thing." Then you'd select a single word and see the entire line change.
We're already using line background color to signal a few things though:
It could be getting a bit overloaded. I'm not sure.