This is not accurate. Most LSPs do provide text editing tools, which the Language Server Protocol calls "code actions". These actions do things like: reorganizing imports, expanding macros, extracting a selection into a function, or converting one type of control flow into another (e.g. if to match). Common LSPs, like rust-analyzer and Ruff (Python) support code actions. Editors also expose code actions: Zed, for instance, exposes actions under the default keymap with the binding Command + .
Come on what are we talking about. Ruff is a linter. Can you show me any LSP server that can move an arbitrary function from file1.ts to file2.ts based on calling it on the command line?
They're not command line applications, they use JSON-RPC inline, and it's an interactive flow, so you need the client to actually persist state.
So what you'd see in the LLM traces, for example, is a couple back-and-forths using JSON-RPC. It absolutely works at the moment, and claude code will happily use it if everything is set up correctly, just tested it using https://github.com/typescript-language-server/typescript-lan...
I was just using it as an example of how dropping claude / gpt in a Linux shell and saying good luck and then giving interviews about spawning sub agents seems to overlook basic text editing primitives
But if you managed to move an arbitrary char range from one file to another using Claude Code talking to the TS LSP server let me know that would be enlightening.
The relevant points have already been made: (1) LSP is a JSON-RPC protocol, not a CLI app, and (2) Language Servers that implement LSP often utilize AST manipulation, even the resultant manipulations are exposed to the client via character ranges.
`ast-grep`, an AST-based search and transformation tool that may be closer in spirit to the cli functionality you describe, albeit more general-purpose:
https://github.com/ast-grep/ast-grep
Interesting. But I think this also proves my point that if this particular LSP server has the move statements functionality the pattern is not default integrated into Claude Code, OpenAI Codex, etc. Like you’d have to figure out a way to keep this server running yourself as if you were running Redis and asking the harness to manage your ToDos in it or something
Jesus christ dude, what you're describing is what an LSP is. It is a server that runs, and integrates with editors, and claude code uses the LSP the same way an editor does. It does, in fact, stay running in the background along side claude code as an independent process. There's no "gotcha" here.
Again this is exactly equivalent to saying Claude Code doesn’t need a todo tool (which it has ie TaskList) cause you can run Redis. What you have demonstrated is that there is a lengthy workaround depending on if a particular LSP server implements a move method .. to do text editing
No, not an arbitrary character range, it's quite a lot smarter than that. It's an AST transformation - it takes the parsed tree out and puts it in another file and updates any imports that refer to the prior function to the new location. That all happens in the LSP side, not the LLM side, so it's deterministic. You can look at the source code for the LSP yourself.
You're basically just agreeing with the original comment that these tools don't do what's stated.
And in my experience, Claude Code will often ignore LSPs, despite instructing Claude to use them and have them installed through Claude, and revert to using grep and sed.
it does look to have a method for moving a function to a new file
I give my agent access to go pls and find it overall beneficial, based on vibes eval. Its way easier to ask LSP everywhere a function or field is used versus grep, saves a lot of tokens
I've had decent results telling agents to use emacs for structural editing operations. Pretty rare that I need to move a function across files verbatim but that should only be a few extra lines of elisp.
Comments
This is not accurate. Most LSPs do provide text editing tools, which the Language Server Protocol calls "code actions". These actions do things like: reorganizing imports, expanding macros, extracting a selection into a function, or converting one type of control flow into another (e.g. if to match). Common LSPs, like rust-analyzer and Ruff (Python) support code actions. Editors also expose code actions: Zed, for instance, exposes actions under the default keymap with the binding Command + .
source: https://microsoft.github.io/language-server-protocol/specifi... and https://microsoft.github.io/language-server-protocol/specifi...
Come on what are we talking about. Ruff is a linter. Can you show me any LSP server that can move an arbitrary function from file1.ts to file2.ts based on calling it on the command line?
They're not command line applications, they use JSON-RPC inline, and it's an interactive flow, so you need the client to actually persist state.
So what you'd see in the LLM traces, for example, is a couple back-and-forths using JSON-RPC. It absolutely works at the moment, and claude code will happily use it if everything is set up correctly, just tested it using https://github.com/typescript-language-server/typescript-lan...
What did you test exactly?
Look what I’m asking for is not complicated
Node cutpaste.js inputpath startcharnum endcharnum outputpath startcharnum
I was just using it as an example of how dropping claude / gpt in a Linux shell and saying good luck and then giving interviews about spawning sub agents seems to overlook basic text editing primitives
But if you managed to move an arbitrary char range from one file to another using Claude Code talking to the TS LSP server let me know that would be enlightening.
The relevant points have already been made: (1) LSP is a JSON-RPC protocol, not a CLI app, and (2) Language Servers that implement LSP often utilize AST manipulation, even the resultant manipulations are exposed to the client via character ranges.
Still, these links may be of interest:
TypeScript’s language-service implementation of the “Move to file” refactor: https://github.com/microsoft/TypeScript/blob/main/src/servic...
Documentation for how `typescript-language-server` exposes that refactor as an opt-in code action: https://github.com/typescript-language-server/typescript-lan...
`ast-grep`, an AST-based search and transformation tool that may be closer in spirit to the cli functionality you describe, albeit more general-purpose: https://github.com/ast-grep/ast-grep
Interesting. But I think this also proves my point that if this particular LSP server has the move statements functionality the pattern is not default integrated into Claude Code, OpenAI Codex, etc. Like you’d have to figure out a way to keep this server running yourself as if you were running Redis and asking the harness to manage your ToDos in it or something
Jesus christ dude, what you're describing is what an LSP is. It is a server that runs, and integrates with editors, and claude code uses the LSP the same way an editor does. It does, in fact, stay running in the background along side claude code as an independent process. There's no "gotcha" here.
Again this is exactly equivalent to saying Claude Code doesn’t need a todo tool (which it has ie TaskList) cause you can run Redis. What you have demonstrated is that there is a lengthy workaround depending on if a particular LSP server implements a move method .. to do text editing
No, not an arbitrary character range, it's quite a lot smarter than that. It's an AST transformation - it takes the parsed tree out and puts it in another file and updates any imports that refer to the prior function to the new location. That all happens in the LSP side, not the LLM side, so it's deterministic. You can look at the source code for the LSP yourself.
You're basically just agreeing with the original comment that these tools don't do what's stated.
And in my experience, Claude Code will often ignore LSPs, despite instructing Claude to use them and have them installed through Claude, and revert to using grep and sed.
not sure if Go pls supports moving between files, but it does have some sophisticated edit features
https://go.dev/gopls/features/transformation
it does look to have a method for moving a function to a new file
I give my agent access to go pls and find it overall beneficial, based on vibes eval. Its way easier to ask LSP everywhere a function or field is used versus grep, saves a lot of tokens
I've had decent results telling agents to use emacs for structural editing operations. Pretty rare that I need to move a function across files verbatim but that should only be a few extra lines of elisp.