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:

• generates a new source file in the same dir named after the first of the items i selected
• moves all selected items into this new source file
• refactors all import statements in the rest of my project that reference any of these items to import them out of the new source file
• in the original source file, cleans up any imports that were exclusively used by these items
• new source file accordingly also has those imports automatically inserted at the top

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:

  the LSP specification (as of my last update in April 2023) doesn't natively support sending arbitrary additional inputs for a standard textDocument/codeAction request. The parameters for this request are typically limited to:
  The text document's URI.
  The range within the document.
  The context, which includes diagnostics.

  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.