search

abingham / traad

An JSON+HTTP server for the rope Python refactoring library
MIT License
107 stars 20 forks source link

Consider how to deal with unsaved files #38

Closed abingham closed 6 years ago

abingham commented 11 years ago

What should we do if someone tried to refactor a buffer which is not saved? Performing the refactoring can lead to a messy situation. Perhaps we should disallow it, or perhaps have a variable that controls what to do.

asmeurer commented 10 years ago

The whole writing to the filesystem situation makes me a bit uneasy. It goes completely against what I would expect an emacs plugin to do.

Would it be possible to load the whole project into buffers in emacs, and make rope do the entire refactoring in-buffer. Traad could then provide some nice interface to see what files are then "modified", or even to automatically save them if you want. Or is reading/writing from the filesystem hard-coded into rope's APIs?

abingham commented 10 years ago

It's possible to ask rope what files will change, and I think even to find out how they will change. So in principle we could get this information over to emacs, open all of the files that need to be changed, and do them in emacs. I don't like this approach for a number of reasons, though.

First, it means potentially opening thousands of buffer for a really large refactoring. This isn't terrible, but it would take time.

Second, if we decide that this is how traad works, i.e. that clients have to the actual refactoring application, then we substantially complicate client development. This is something I want to avoid...simple client development is a goal of traad.

Finally - related to the second point - the approach you mention strikes me as the wrong separation of concerns. Rope is already able to make the changes to the files, and emacs is already able to detect changed files and revert buffers automatically. Asking emacs to also make the changes feels like extra work for no benefit except expectation violation.

So obviously I'm pretty hesitant to make a change like this. With that said, I've been wrong enough times that I like to keep an open mind, so try to convince me if you think there's a strong reason to do things differently!

abingham commented 10 years ago

We could also consider parallel functionality. I'm already thinking about adding a sort of "preview mode" for refactorings whereby the server would ship the calculated changes over to the client without actually making them. Once this is in place it's not too hard to see how clients could - if they chose - perform the refactorings themselves. It seems that this would make it relatively easy to create an extension to traad which does the refactorings locally.

asmeurer commented 10 years ago

I guess I'm just still unused to the idea of an editor command changing other files from the one I am currently editing.

abingham commented 10 years ago

Those kinds of "distant changes" are in the very nature of certain refactorings, so I don't see how we could realistically avoid doing them. For example, if you rename a class at its definition without also updating all of the places where that class name is used, then you haven't really done a refactoring...you've just broken your program.