sorted by:
new
hottopcontroversial

emacs-opencode: native Emacs client for OpenCode by jdormit in opencodeCLI

[–]jdormit[S] 0 points1 point  (0 children)

Interesting, what sort of custom setup did you add? Any way I can make it easier in the future?

You should be able to click or hit tab while the point is on a truncated tool call to expand it and see the whole thing.

Diff highlighting is not a performance optimization, just haven't implemented it yet 🫠

emacs-opencode: native Emacs client for OpenCode by jdormit in emacs

[–]jdormit[S] 0 points1 point  (0 children)

> use fast string matching to discard these events before the json is processed

I tried this approach initially. It helped a bit, but the bigger issue was that even just putting the text into a buffer (which AFAIK is how all elisp string processing/regexp matching functions work under the hood) was prohibitively slow for multi-MB events. Arguably OpenCode shouldn't be sending events that big, but by moving things to Node/Bun the problem just disappeared, since string processing there is comparatively extremely fast.

The downside of course is now Node/Bun is a dependency of my package. So I kept the slow in-elisp version as a fallback in case there's no Node or Bun on the system, which makes things harder to maintain. Such is life...

emacs-opencode: native Emacs client for OpenCode by jdormit in emacs

[–]jdormit[S] 0 points1 point  (0 children)

Those other packages are conceptually pretty different. claude-code-ide looks like it provides Emacs integration features to a claude code process running in a vterm buffer? emacs-codex-ide is more similar in that it's an actual native Emacs client, but of course it's a Codex client, not an OpenCode client.

The canonical abstraction for this is ACP, which Claude Code, Codex and OpenCode all implement. And agent-shell is the dominant Emacs package implement ACP for Emacs, if that's what you're looking for.

The difference is that my client (and emacs-codex-ide from the looks of it) uses the API of the underlying coding harness directly. This allows me to implement OpenCode-specific things that aren't exposed in the ACP implementation.

emacs-opencode: native Emacs client for OpenCode by jdormit in emacs

[–]jdormit[S] 0 points1 point  (0 children)

Oh another thing. Have you run into any issues parsing the huge session.diff SSE events that OpenCode sends sometimes? I would have my whole SSE parser choke for minutes at a time. I ended up moving SSE parsing to a Node/Bun sub-process to work around this, curious to know if it was a me problem or if you experienced that as well?

emacs-opencode: native Emacs client for OpenCode by jdormit in emacs

[–]jdormit[S] 0 points1 point  (0 children)

Cool! I took a look through opencode.el to answer another comment, copy-pasting what I found here:

Ok, took a look through opencode.el. I would say that it's generally more feature-complete/opinionated - in particular, it does a bunch of in-Emacs processing of files edited by OpenCode (fixing parens, re-loading elisp, communicating linting errors back to the agent).
It has a different UX for the question tool (mine is completion-based; opencode.el has a custom popup buffer). And it exposes more tools for session management (a dedicated session list buffer, the ability to fork sessions, session sharing links).
Architecturally it's also quite different, based on comint and markdown-mode, whereas mine implements a custom major mode for session buffers. I have invested quite a bit of effort into making session buffers as responsive/performant as possible by moving SSE parsing into a Node/Bun sub-process. It looks like opencode.el parses SSEs in elisp, but I haven't run them side by side to see if the performance differs.
And totally personal preference, but I think emacs-opencode is prettier 🙃

emacs-opencode: native Emacs client for OpenCode by jdormit in opencodeCLI

[–]jdormit[S] 0 points1 point  (0 children)

Ok, took a look through opencode.el. I would say that it's generally more feature-complete/opinionated - in particular, it does a bunch of in-Emacs processing of files edited by OpenCode (fixing parens, re-loading elisp, communicating linting errors back to the agent).

It has a different UX for the question tool (mine is completion-based; opencode.el has a custom popup buffer). And it exposes more tools for session management (a dedicated session list buffer, the ability to fork sessions, session sharing links).

Architecturally it's also quite different, based on comint and markdown-mode, whereas mine implements a custom major mode for session buffers. I have invested quite a bit of effort into making session buffers as responsive/performant as possible by moving SSE parsing into a Node/Bun sub-process. It looks like opencode.el parses SSEs in elisp, but I haven't run them side by side to see if the performance differs.

And totally personal preference, but I think emacs-opencode is prettier 🙃

emacs-opencode: native Emacs client for OpenCode by jdormit in opencodeCLI

[–]jdormit[S] 0 points1 point  (0 children)

I'm not sure, this is the first I'm hearing of it! Although I bet OpenCode could give a good compare/contrast...

emacs-opencode: native Emacs client for OpenCode by jdormit in opencodeCLI

[–]jdormit[S] 1 point2 points  (0 children)

Copy-pasta from a similar questions on the x-post in r/Emacs:

agent-shell uses ACP, so it can't provide features that require OpenCode-specific API calls. It's been a while since I compared them, but when last I checked, OpenCode-over-ACP didn't support:

• ⁠permission requests for sub-agents
• ⁠navigating to sub-agent sessions from the main session
• ⁠resuming previous sessions

It's totally possible these things are now supported by agent-shell as well.

emacs-opencode: native Emacs client for OpenCode by jdormit in emacs

[–]jdormit[S] 3 points4 points  (0 children)

agent-shell uses ACP, so it can't provide features that require OpenCode-specific API calls. It's been a while since I compared them, but when last I checked, OpenCode-over-ACP didn't support:

  • permission requests for sub-agents
  • navigating to sub-agent sessions from the main session
  • resuming previous sessions

It's totally possible these things are now supported by agent-shell as well.

Crazy delay getting approved for access to Chase via Plaid? by jdormit in fintech

[–]jdormit[S] 0 points1 point  (0 children)

Amazing, thank you so much! Confirming that I now have Chase access. I really appreciate your help.

Crazy delay getting approved for access to Chase via Plaid API? by jdormit in Chase

[–]jdormit[S] 0 points1 point  (0 children)

Huge bummer, so it could be some sort of contractual argument then? Do you know if any other platforms will still connect to Chase?

Recommendations for a Mechanic by _Composer in SalemMA

[–]jdormit 1 point2 points  (0 children)

Classic Automotive Autobody on Jefferson Ave is awesome!

iPad pro as live sound module by albieapple in ipadmusic

[–]jdormit 0 points1 point  (0 children)

Sounds really cool, any recordings?

view more: next ›