Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

History support for multi-project refactorings? #219

Open
abingham opened this issue Oct 18, 2017 · 12 comments
Open

History support for multi-project refactorings? #219

abingham opened this issue Oct 18, 2017 · 12 comments

Comments

@abingham
Copy link
Contributor

Is there any support for doing undo/redo for multi-project refactorings? If not, are there plans for this?

@soupytwist
Copy link
Contributor

I don't think this support exists and is not planned. What is your use case?

@abingham
Copy link
Contributor Author

I'm writing a HTTP server that exposes rope functionality, and I'd like to let users add cross-projects to do multi-project refactorings. It offers undo/redo support for refactorings, and it seems like it would be odd if undo only worked for the root project.

I might be able to manage the multi-project un/redo support myself, but I'd like to avoid the work if it comes natively from rope.

@sergeyglazyrindev
Copy link
Contributor

Oh, I like this idea, I'd like to join this project :)

@abingham
Copy link
Contributor Author

@sergeyglazyrindev Any help is appreciated! I'm in the middle of making some substantial changes, so it's in a weird state. But hopefully I'll have it back to "normal" soon.

@emacsway
Copy link
Contributor

@emacsway
Copy link
Contributor

@abingham , what do you mean "for multi-project"?

@abingham
Copy link
Contributor Author

@mcepl
Copy link
Contributor

mcepl commented Oct 19, 2017

I'm writing a HTTP server that exposes rope functionality,

I like the idea, but wouldn't it be better to support Language Server Protocol? Would it make sense? I believe that creativity around protocols is almost always The Wrong Idea™. This in end, maybe even a good replacement for ropemode, ropevim, and ropemacs. Otherwise apparently the best Python LSP is based on Jedi.

@emacsway
Copy link
Contributor

@abingham , as I see, there is a Composite pattern, which simple delegates calls to the Leaves, see:

There is only one little problem, the non-polymorphic call for the .do() method, see:

I think, we can easy fix this issue, thus, the History class will be able to work with the Composite (_MultiRefactoring) as well as with a Leaf.

@abingham
Copy link
Contributor Author

I like the idea, but wouldn't it be better to support Language Server Protocol?

Maybe so. I started traad because nothing (including ropemacs, since I'm primarily an emacs user) worked for what I needed, and I only really do enough work to make it work for me. If someone wants to put in the effort to create a better refactoring server of some sort, that would be fine with me. FWIW, I definitely feel that an HTTP language server is a better model than pymacs/ropemacs.

@mcepl
Copy link
Contributor

mcepl commented Oct 19, 2017

If someone wants to put in the effort to create a better refactoring server of some sort, that would be fine with me.

So, it won't be you, do I understand correctly?

Just that you could save yourself work on the Emacs-side of the things (and there are even rumours Emacs will have support for LSP natively, and there are already LSP clients for Emacs in existence).

Also, I would love to see rope-based LSP server. If LSP is the future (and it seems to have a great momentum behind it), it could be very neat way how to make rope relevant again (and we could get rid of all three rope{mode,vim,macs} projects which feel to me like the worst part of whole endeavour.

@abingham
Copy link
Contributor Author

So, it won't be you, do I understand correctly?

Currently that's correct. I barely have the bandwidth to keep traad hobbling along.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants