3 ms·
I spent some time trying to understand what OpenCode.nvim gave me, could do for me. It felt mostly like ways to take nvim things and inject them into OpenCode.
by jauntywundrkind 9mo ago
I spent some time trying to understand what OpenCode.nvim gave me, could do for me. It felt mostly like ways to take nvim things and inject them into OpenCode. Which was fine I guess. I'm probably underselling it, but I was hoping for more, and it never really clicked.
https://github.com/nickjvandyke/opencode.nvim https://github.com/nickjvandyke/opencode.nvim
I find myself spending much more time in OpenCode than in nvim these days. With mcp-neovim-server, it's super easy to keep vim open & ask OpenCode to show me, to open files, go to lines. This didn't require any nvim tweaking at all, it's just giving the LLM access to my nvim. It is absolutely wild how good glm-4.7 has been at opening friendly splits, at debugging really gnarly wild nvim configuration problems that have plagued me for years. It knows way way way more nvim than I do, and that somehow surprised me.
https://github.com/bigcodegen/mcp-neovim-server https://github.com/bigcodegen/mcp-neovim-server
Definitely interest in the ACP angle. I feel like we're in a weird spot where ACP is this protocol where the thing you do use talks to the headless thing you don't ever see. I'd love to know or see more than that. These connections feel 1:1, but I want to see human interaction in every agentic system, not for there to be this me -> ide -> ACP agent flow with the ide intermediating all, being the sole UI. It should be able to do that yes!! But I also want an expectation that there can be multiple forces "driving" an ACP service.
I've watched the video now. It's still not crystal clear to me architecturally is going on, but it does seem like a fairly robust emacs shell experience that wraps the agent flow. I really enjoy the idea of having this overlayed compose buffer, that is your editor style input. I'd love to know how that is wired to the agents; is that input sent over ACP? Is that just sending to the shell? This compose buffer feels like it may be a broader emacs pattern. One I'd love to see in nvim! Years ago I had a plugin that would take the selection or current line and send it to a buffer. That was my very crude compose buffer.
- xenodium 9mo ago> It's still not crystal clear to me architecturally is going on [ Emacs ] <-- JSONRPC (stdin/stdout) -> [ Agent subprocess (headless) ] > I'd love to know how that is wired to the agents; is that input sent over ACP? Yes. All traffic goes over ACP between Emacs and the agent. You can inspect the traffic using agent-shell itself. https://github.com/xenodium/agent-shell?tab=readme-ov-file#how-do-i-viewget-agent-client-protocol-traffic https://github.com/xenodium/agent-shell?tab=readme-ov-file#h... > Is that just sending to the shell? The compose buffer is an UX abstraction on top of the agent shell buffer which is a native Emacs buffer, but ultimately all traffic is sent over ACP. agent-shell's links to blog posts may be of interest https://github.com/xenodium/agent-shell?tab=readme-ov-file#news https://github.com/xenodium/agent-shell?tab=readme-ov-file#n...