Why not instead make the IDE's undo operation work as expected when a source file is externally modified?

I think the point is that gorename is used as part of the opaque
implementation of the IDE and not something external as far as the user is
concerned. As such undo seems like a completely reasonable thing for an IDE
to do.

On Sat, Nov 21, 2015 at 8:55 PM, Matthew Dempsky notifications@github.com
wrote:

Why not instead make the IDE's undo operation work as expected when a
source file is externally modified?

—
Reply to this email directly or view it on GitHub
#13355 (comment).

@RLH That's right. Editors/IDEs undo stacks never include edits to files made outside of the editor as far as I'm aware. Any action invoked by the user inside the editor is expected to make its modifications to editor buffers via the editors own text buffer APIs so that those edits are tracked on the undo stack. Pretty sure all of that is standard across tools.

So to have undo support, we would need forename to provide the set of edits and the editor plugin to actually apply these using the editors APIs.

Output in unified diff (or similar) format will also allow IDEs to show preview of the changes before applying them.

@kostya-sh Agreed - using the same rendering as gofmt -d to provide a diff would allow tools to use the same logic they are using for processing gofmt edits for gorename as well.

/cc @alandonovan

https://go-review.googlesource.com/#/c/18208/