Live data from Hacker News

Claude Code IDE integration for Emacs

github.com

61–70 of 281 posts

Re: Claude Code IDE integration for Emacs

#61
post #12

Earlier quoted context omitted.

Is there a standard for integrating agentic coding tools into an editor similar to how an LSP allows the integration of language-specific features?

Its not at anything like the adoption of MCP or especially LSP, and it takes a more "foundational and composable library of primitives" approach than "wire protocol per se" approach, but `gptel` has quite the vibrant little ecosystem around it and its just god mode, wall hacks on the VSCode stuff, just blows it away. I'm under extreme time pressure at the moment, I cannot afford to fuck around on ideology right now I…

Are you using gptel exclusively, or also things like aider/claude code?

I’d love to hear more about your workflow if you have time to share!

Re: Claude Code IDE integration for Emacs

#62
I’ve always thought emacs is the ultimate editor for AI agents. The agent has so much access to the state of the editor itself and can even easily change editor behavior with elisp. I feel like editors which expose the level of customization like vim and emacs could potentially have a huge advantage.

Re: Claude Code IDE integration for Emacs

#63
post #2

Pretty cool! I love that these battle proven editors (emacs and (n)vim) seem to follow along with new technology, even though one might think overwise given their age. I hope this comes to vim as well!

Neovim and to an extent emacs are where corporate IDE vendors go for ideas. From ergonomics of the UX, performance, portability, design sense (!!) and theming? It's like Sun and GNU in the 90s. Those UI/UX folks getting pissed their perfect HSL wheel and black balance got dicked with by some PM which is why the GitHub theme is great not legendary? They go home and rice Arch or NixOS and just shit on the dayjob stuff.…

You must understand that a screenshot of your black balance cannot translate to another screen?

Re: Claude Code IDE integration for Emacs

#64
post #55
post #36

Earlier quoted context omitted.

This is due to Richard Stalllman. He thinks that integrating "non-free" alternatives when free alternatives don't yet exist slows down free software development. Not just free as in freedom alternatives, not just free as in GPL licensed, but free as in FSF controlled projects. He did the same thing with linking extensions to GCC, LLVM debugger integration into emacs (fuzzy on that one), possibly treesitter into emacs…

You clearly misunderstood the problem. The entities he is so adamant against are not benign or passive, they actively try to capture your freedom for rent seeking behaviour. Microsoft, Apple, Amazon etc, have not got to where they are without this behaviour and they are so powerful that they have in many cases captured even public money from large governments for decades and are exceptionally sticky once allowed in.…

I haven't misunderstood the problems that RMS talks about, I agree with his prescient analysis. I firmly disagree that RMS the person is the best person to lead a software producing organization that aims to deliver a free future.

A simple reductive example. Imagine a great software leader that leads an org that writes great code and generally achieves the org's goals, but once a week, they say something offensive that discourages 1/10th of new users. A better leader would be someone who does all of the same things, except for the offensive comments.

I am saying that RMS makes offensive distracting comments, and regularly makes project manager choices that slow the adoption of free software. If you criticize him, people come back to "but he's right philosophically" which he is, and that misses the point. He has wrapped the FSF into an ego play for himself where he is in control or at least an important roadblock to software progress. If RMS cared as much about software freedom (as opposed to his ego) as he says, he would work to allow better leaders to develop and have power in the FSF org.

Re: Claude Code IDE integration for Emacs

#66
post #36

Earlier quoted context omitted.

This is due to Richard Stalllman. He thinks that integrating "non-free" alternatives when free alternatives don't yet exist slows down free software development. Not just free as in freedom alternatives, not just free as in GPL licensed, but free as in FSF controlled projects. He did the same thing with linking extensions to GCC, LLVM debugger integration into emacs (fuzzy on that one), possibly treesitter into emacs…

Where would they integrate it. Emacs is a small core of C code. Almost everything is Elisp and in the same standing as third party packages. I’m not seeing what being in emacs core brings to an AI package?

Well the linking into GCC was a C code issue. For emacs, there is a large collection of elisp that is shipped with the official package. Preventing worthy enhancements of that core package solely in the name of a distorted view of freedom hinders emacs and the adoption of emacs.

Re: Claude Code IDE integration for Emacs

#67
post #61

Earlier quoted context omitted.

Its not at anything like the adoption of MCP or especially LSP, and it takes a more "foundational and composable library of primitives" approach than "wire protocol per se" approach, but `gptel` has quite the vibrant little ecosystem around it and its just god mode, wall hacks on the VSCode stuff, just blows it away. I'm under extreme time pressure at the moment, I cannot afford to fuck around on ideology right now I…

Are you using gptel exclusively, or also things like aider/claude code? I’d love to hear more about your workflow if you have time to share!

Sure. I'm experimenting like everyone else, but I mostly use gptel as the primary interaction surface and Claude Code for a range of refactorings and other "more than mechanical, less than creative" edits. Both of these are very (!!!) well complimented by magit, which is so good at AI supervision it seems designed for it, by a genius.

For Claude Code I'm rapidly switching anything I want "vibe coded" into Hadkell for code, Dhall for config, and check-heavy Nix for deploy. Between that and some property tests that I seed and then have Opus elaborate on, you can put Claude Code so restrictive that it just hits the compiler in a loop until useful code comes out. Its trapped: I hoist CLAUDE.md in from the Nix store so it physically can't edit out the brutal prompts around mocks and lies, and -Wall -Werror in GHC gives it nowhere to hide, all it can do is burn tokens and desperately Web Search tool until it gets it perfect ish or I cut off its money because this requires a real LLM minimum and likely a real programmer. If there's a property test welded into the type system it can't even fail to use a parameter: that's an error Claude.

I have a bunch of elisp in // hypermodern // emacs for things like OpenRouter integration and tool use, but frankly, stock gptel is so strong I always wonder if I'm getting my money's worth trying to tune it into the asymptote.

Happy to answer any more questions.

Re: Claude Code IDE integration for Emacs

#68
I wonder if this can work with OpenCode (Claude Code fork which allows for other model providers: https://github.com/sst/opencode)?

I really don't like being tied to a particular provider or model, switching models has been really helpful to get past blocks and save money (especially with Deepseek!).

And, of course, I need to use Github Copilot's Open AI-compatile API at work...

Re: Claude Code IDE integration for Emacs

#69

Earlier quoted context omitted.

Neovim and to an extent emacs are where corporate IDE vendors go for ideas. From ergonomics of the UX, performance, portability, design sense (!!) and theming? It's like Sun and GNU in the 90s. Those UI/UX folks getting pissed their perfect HSL wheel and black balance got dicked with by some PM which is why the GitHub theme is great not legendary? They go home and rice Arch or NixOS and just shit on the dayjob stuff.…

You must understand that a screenshot of your black balance cannot translate to another screen?

I do understand that. I was just illustrating that it's possible to do very holistically integrated desktops programmatically and in a way where you can do some math once and leverage it again.

I'm personally a fan of `ono-sendai-blue`, but I have a friend in a defense adjacent space and I gather `ono-sendai-tactical` is enjoyed there. The blacks in these reference palettes are a reasonable starting point for many displays, you'll want to hint for your specific one to get optimal outcomes.

https://gist.github.com/b7r6/581295d8bb905ef598a05fdf2810a07...

https://gist.github.com/b7r6/fbbfb1cf2a3d14927bbe621a9050522...

Re: Claude Code IDE integration for Emacs

#70
While I'm happy that simultaneously there are at least 5 known Emacs/Claude Code integration packages, with seemingly 2 or 3 battling it out on Reddit and elsewhere, I feel like the best implemented one is the quiet one that no one has ever talked about.

https://github.com/yuya373/claude-code-emacs <- it literally implements every feature that every other ones have.

Post reply on HN