Replies: 2 comments 1 reply
-
|
VSCode has a code action named "move to file", which implements the functionality you want. It is currently impossible to implement this according to standard LSP, but possible through defining custom protocol extension. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Thanks i will give that a shot and see if i can get this working in vscode and then investigate how to go about it in neovim. |
Beta Was this translation helpful? Give feedback.
-
|
Also tracked in this issue #863 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This code action is stupendously powerful. I am using neovim and I can use a range code action to refactor entire swathes of code. It:
Needless to say this is going to save a lot of module import refactoring headaches and I am committed to leveraging automations like this as the new de facto workflow... the presence of this automation frankly makes me not want to use any other programming language...
My question is, how should I approach trying to make this particular code action more than only being useful for "breaking code apart into more files" workflows? I would like to be able to specify a target file to move some selected items into, rather than for a new filename to be automatically inferred.
There is another plugin that i use which communicates to the LSP about filesystem actions performed, so I am able to use this code action and then rename the automatically created new file into a name that I want, this is very useful, however still does not address the issue that there's simply no way to move items freely between existing files. We can only freely break code into ever smaller code files and rename them.
More specifically:
Does "Move to a new file" already accept a specified existing file to target?
If not, it is clear that the building blocks needed to make such a functional extension to this action are already present. But, does the LSP protocol allow for us to provide input from the editor side of a target file path? What other challenges might exist here? GPT4 tells me:
I am inclined to believe this. If this is the case, then, what would be the most reasonable approach forward? Are there any extensions to the LSP protocol that can support this that we can start to implement? It's curious to me that the LSP protocol would support being able to send in a code position range but won't let us send in a target file path, or that there can't be a reply from the LSP server to ask for further information. I wouldn't mind in the short term doing "Move to a new file" first and triggering another code action from the existing target file, but it would also appear to be impossible to communicate to it all the details of that first action without resorting to sketchy out-of-band approaches, although in this case caching the path of the newly created file should in theory provide all of the necessary information.
Beta Was this translation helpful? Give feedback.
All reactions