Use Language Server Protocol (LSP) to re-implement all code editing
What problem or use case are you trying to solve?
OpenDevin now sometimes suffers with edit command (concrete example: https://github.com/OpenDevin/OpenDevin/pull/1928).
Describe the UX of the solution you'd like
As suggested by a friend @ganler, maybe it is more like a fundamental solution if we can gradually replace all the swe-agent tools to interface with a Language Server Protocol:
It gives us the ability to:
- Open file
- Change/edit file
- Go to the definition of a symbol
- More importantly, this is actually scale to multiple programming languages!
Do you have thoughts on the technical implementation?
- [ ] Starts with translating the existing bash command's implementation to an API call to the language server (e.g., open, edit, etc)
- [ ] Figure out a better interface for editing -- current HEREDOC + bash causes many weird issues. Can we potentially use
IPythoncapability for editing, write these file operation functions in Python, and have the model write and execute Python cells to perform file operations? -- can directly wrap around https://github.com/microsoft/monitors4codegen?tab=readme-ov-file#4-multilspy - [ ] Support more advanced features, like going to the definition
- [ ] Automatically supports multiple language servers for most existing programming languages.
- [ ] Show VSCode warning / problems
Describe alternatives you've considered
Additional context
Oh nice! ~~I have worked with LSP before! I could probably contribute to this.~~
LSP has a general interface to interact with. But if we want to start with some very easy, Jedi can be a great starter in my experience. :)
https://jedi.readthedocs.io/en/latest/docs/api.html#examples
For more general cases of interactions, monitors4codegen has some examples using multilspy to interact with some LSP implementations.
https://github.com/microsoft/monitors4codegen#4-multilspy
FYI, Devin (the closed one) is fully integrated with VS Code. That means it has access to all the extensions, linting, and debugging tools. I think this is something to consider
I wonder if LSP can also actually edit the files, in addition to just monitoring file changes (usually user-triggered) and provide completion suggestions, etc.
For the VSCode solution, maybe incorporating the full VScode is heavy, but the underlying editor of vscode, monaco, could be a good option. Alternatively, CodeMirror is also quite minimalist. These editors usually maintain editor state, including undo stack as well so that if the agent is doing something wrong, we can let it call "undo" function.
For the edit command replacement, the closest might be: https://microsoft.github.io/monaco-editor/typedoc/interfaces/editor.ICodeEditor.html#executeEdits , or https://codemirror.net/examples/change/
Is it a good idea to incorporate complex LSP protocol with agent?
I wonder if LSP can also actually edit the files, in addition to just monitoring file changes (usually user-triggered) and provide completion suggestions, etc.
For the VSCode solution, maybe incorporating the full VScode is heavy, but the underlying editor of vscode, monaco, could be a good option. Alternatively, CodeMirror is also quite minimalist. These editors usually maintain editor state, including undo stack as well so that if the agent is doing something wrong, we can let it call "undo" function.
For the
editcommand replacement, the closest might be: https://microsoft.github.io/monaco-editor/typedoc/interfaces/editor.ICodeEditor.html#executeEdits , or https://codemirror.net/examples/change/
LSP models cursors and code locations & ranges. And knowing the locations it's easy to insert code, isn't it ;).
Good point. @ganler I wonder who maintains the cursor and code location states? (the editor states). For a real editor there's actual editor states, but it seems like we still have to maintain an "headless" editor in the backend
This may also be another alternative/useful exploration:
- #742
This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.
This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.
This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.
This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.
cc @ryanhoangt who is potentially interested in this
Hi all, I am the author of Microsoft's monitors4codegen and multilspy repositories. I would be glad to help in any way possible with integrating LSP support in OpenHands.
Hi @LakshyAAAgrawal, thanks for offering your help! I've tried to integrate multilspy into the openhands-aci before (at this branch) but didn't finish it. Would be great if you can have a look to see if we can integrate it as a module into the aci!
This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.
Hi all!
I apologize for not being able to follow up on this soon. Does anyone have ideas/suggestions for what are the main parts that require multilspy (https://aka.ms/multilspy) integration? My suggestion would be to start with one small feature that some current solution can be replaced by lsp, and then slowly expand the set of locations. Since I am new to Openhands, it would be great if anyone could advise about what might be the best place to start with integration!
This is probably not planned for the team now. We currently implement every file editing in the https://github.com/All-Hands-AI/openhands-aci repo -- We can possibly implement ACI there.
Happy to re-open this if anyone in the community is interested in implementing this :)