Go Doctor interactive mode? about godoctor HOT 2 CLOSED

this is an interesting idea. on the one hand it would be really nice for us to only have to maintain basically this to do all the heavy lifting, with light integration into editors, instead of duplicating a lot of work. but on the other hand i'm not sure that it will be a "familiar" experience for users across different text editors and in a lot of scenarios users will want "fast path" kind of refactoring for smaller refactorings. this would also seem to entail some kind of separate tool to run to start a refactoring and i think in general refactorings will probably mostly be used by invoking through an editor (not that the editor couldn't invoke the tool, sure).

this idea got my wheels turning a bit, so here goes some spit balling. I was thinking back on how we by default poop out a patch file to apply. Maybe it would be easy enough to feed the patch file into each of the different editors to view? It may be the case that we would need to take the files as they are, copy them to tmp, apply the patch file, and then "diff" the original with the patched version in each editor, but each editor seems to have this kind of functionality at least out of the box (this is as opposed to applying the "patch" directly to the original files, as we have been in editors). Then I guess it becomes an issue of how to make this intuitive. If you have vim open (to run the refactoring) we could open a new tab and do this wizardry. For sublime text pop out a new window. Emacs, whatever their thing is that is clearly better than every other editors' thing. This could be in addition to the "normal" flow, the "interactive" flow as you have described it (i think this is on the same page?). And I guess it would be not a whole lot of additional code to our plugins now as it's basically changing which files we're patching, then adding a little sugar to complete the whole thing (and maybe rollback). Need to study how IDEs have done it [more/again]. I'd guess they are keeping state and treating refactorings like actions that can be undone easily enough. I can think of small issues with this like, if they changed the original files since we write out the patch file then how do we resolve that (yay computers). but anyway, maybe this train is derailed from where you were trying to go?

from godoctor.

I didn't describe this very well, but you got the idea. Basically, I was thinking you would trigger the refactoring from Vim/Sublime/whatever, Go Doctor would pop up a UI to preview the changes and (if you tell it to) change the files on disk, then it would exit and you'd be back in your editor.

My real concern was renaming refactorings that affect multiple files. The way single-file refactorings are currently integrated with Vim works well IMHO (modify the buffer and don't save, so u can undo) -- no need to change that. The multi-file Vim integration works but is kludgy. I think we've discussed that before. :)

Anyway, I agree. Vim has its diff mode, emacs apparently has something like that, not sure about Sublime... so the time's probably better spent trying to figure out if we can leverage that. I'll try to see what the options are for multi-file patches in Vim and reopen this if necessary.

from godoctor.