Live data from Hacker News

Claude Code IDE integration for Emacs

github.com

271–280 of 281 posts

Re: Claude Code IDE integration for Emacs

#271

Earlier quoted context omitted.

To start, I disagree. If it takes a person to turn away from a tool just because some random human tool said something online, maybe they are not ready, on what level - emotional, spiritual, mental, moral - I'll leave them to decide. I'm not saying "don't dabble in Emacs", dable all you want. Just use the damn tool - it's not that hard. To use the tool you just need to use the fucking tool with the intent to fucking…

Evangelism takes at least two forms: - You're a sinner, a wrong-doer, and you must repent. - This world you have not yet experienced is wonderful. Let me tell you about it. Many, probably most, respond better to the second form.

My message in this particular instance is not aligned with either of these, and you seem to be misreading me. I have no issue with people choosing different tools, switching techniques, finding different ways of thinking about problem solving, text-editing, etc. It's not even about "punishing" those who choose to leave my beautiful world or trying to get them back, it's about setting expectations for those who have never seen it.

What I see quite often is when people profess years of using the tool and finding it unsatisfactory, only to reveal (if ever) that they've engaged with just its surface layer. It's like someone saying they found a piano limiting after years of only using it as a percussion instrument. My point is about embracing Emacs as a Lisp environment from day one - not because everyone must use it this way, but because that's what it actually is. When you treat it as 'just an editor' you're working against its design rather than with it. Those who embrace its programmable nature early often discover possibilities they didn't know they were looking for. Yes, this may mean a slightly steeper upfront commitment, but it also means actually using the tool rather than having square-peg-round-hole mismatched expectations.

It's not about choosing nicer or harsher messaging, it's about the truth, and it comes from the heart - I personally, of course, regret years wasted in vain instead of finding Emacs sooner; it works great for me. I understand it may not work that well for everybody, and I'd rather they realize that sooner, instead of wasting years of their lives. I also spent a long time trying to rationalize Emacs in my own head, because I kept approaching it from the wrong angle, but I am happy I didn't quit. Some people may not have that kind of patience.

Re: Claude Code IDE integration for Emacs

#272

Earlier quoted context omitted.

> people who shouldn't be talking about CS. Dijkstra said computer science is about computers as much as astronomy is about telescopes. I am not sure I agree with that, but it's definitely not about text editor choice. I have a .vimrc file with LSPs and whatnot. But it was from 3 years back. These days I use VSCode and IntelliJ (depending on language) because they do so many things out of the box. I would say the cho…

> I am not sure I agree with that, but it's definitely not about text editor choice. It's definitely possible but I genuinely don't understand how people work for decades and still move their hand all the way to the arrow keys just go move the cursor to another word. Especially when the solution for this inefficiency is so accessible, existed for decades and is widely available in almost every tool. It's something th…

It’s not the bottleneck of true productivity. It doesn’t matter any more than how close the pedals are together would affect how long it takes me to drive somewhere.

Re: Claude Code IDE integration for Emacs

#273

Earlier quoted context omitted.

Evangelism takes at least two forms: - You're a sinner, a wrong-doer, and you must repent. - This world you have not yet experienced is wonderful. Let me tell you about it. Many, probably most, respond better to the second form.

My message in this particular instance is not aligned with either of these, and you seem to be misreading me. I have no issue with people choosing different tools, switching techniques, finding different ways of thinking about problem solving, text-editing, etc. It's not even about "punishing" those who choose to leave my beautiful world or trying to get them back, it's about setting expectations for those who have n…

> When you treat it as 'just an editor' you're working against its design rather than with it.

No. This is exactly the sort of talk that turns people off from Emacs. You can use it as "just an editor." Indeed, read the GNU Emacs Manual. It almost entirely describes "just an editor." An excellent editor. The user needs to consult the Emacs Lisp Reference Manual only if extending Emacs is desirable.

Comments like this one suggest that Emacs is designed only to be programmed and that if the user does not program it, the user is "working against its design." This is just as false as saying that a Vim user who writes no VimScript is working against Vim's design. No, the user who doesn't program the editor is...using the editor. As designed.

Re: Claude Code IDE integration for Emacs

#274
post #215

Earlier quoted context omitted.

My experience aligns with this. I work for a bigco. Yet to meet a fellow Emacs user.

Don't y'all have a #emacs slack channel or equivalent at your company? I work for a medium-sized tech company and we have a single digit amount of emacs users I feel like. The channel is mostly dead except for a few tips and tricks and the odd time people asking how we each install it on our macbooks. Anecdotally a lot of managers use Emacs, though that may be an age thing. (I use emacs for Real Work, unless that Rea…

Yep. I do as much real work as possible in Emacs. Magit/Org-Mode/Org-roam/Org-gtd/Babel are all pretty essential to my workflow.

Re: Claude Code IDE integration for Emacs

#275

Earlier quoted context omitted.

My message in this particular instance is not aligned with either of these, and you seem to be misreading me. I have no issue with people choosing different tools, switching techniques, finding different ways of thinking about problem solving, text-editing, etc. It's not even about "punishing" those who choose to leave my beautiful world or trying to get them back, it's about setting expectations for those who have n…

> When you treat it as 'just an editor' you're working against its design rather than with it. No. This is exactly the sort of talk that turns people off from Emacs. You can use it as "just an editor." Indeed, read the GNU Emacs Manual. It almost entirely describes "just an editor." An excellent editor. The user needs to consult the Emacs Lisp Reference Manual only if extending Emacs is desirable. Comments like this…

> You can use it as "just an editor."

You can, sure - sometimes we all do, when we need to debug a faulty package, we run it with the -Q option. I've been working for many years with people who use Emacs, have many friends who use Emacs, have mentored complete newbies and regularly discuss advanced topics - I have yet to meet someone who uses Emacs as is - with no customizations whatsoever. In fact, if I meet anyone who does that, I would very much be interested in learning their rationale, and perhaps even try to question their mental or emotional state.

Vim on the other hand, is very different in this, there are in fact plenty of users who do use it with zero customizations, daily.

> read the GNU Emacs Manual.

Okay. Let's do it... M-x info-emacs-manual - the very first two sentences - "Emacs is an advanced, extensible, customizable, self-documenting editor. This manual describes how to edit with Emacs and some of the ways to customize it." The third paragraph right there, at the very top, already explicitly says: "For information on extending Emacs, see Emacs Lisp". Five words pertaining extensibility in just three opening paragraphs, against only a couple of cognates of "editor".

What the heck are you even trying to argue here? Rephrasing your point doesn't change the underlying fact - Emacs is first and foremost an "extensible editor", not "an editor that can be extended (if desired)" - the emphasis is on "extensible", not on the "editor". That's what sets it apart from literally any other tool that gets used as "just an editor".

If regurgitating the factuality engrossed in the manual, ardently or otherwise, turns some people off from Emacs - so be it, like I already said before - it's probably for the best. Better for them, better for the Emacs community.

Re: Claude Code IDE integration for Emacs

#276

Earlier quoted context omitted.

You think VIM is a niche? neovim + vim is used by over 38% of developers according StackExchange survey. That is more than 1 out of 3 developer, closer to 2 out of 5. I am not sure what is going on with here recently, maybe I have overgrown the place, or maybe everyday a little by little this place is getting filled with people who shouldn't be talking about CS.

> with people who shouldn't be talking about CS Your argument is that calling Vim niche should exclude someone from being able to talk about CS. Please rethink your stance and your tone and consider if you’re helping the discussion.

This is a much more hostile and unproductive comment than the one you're replying to

Re: Claude Code IDE integration for Emacs

#277

Earlier quoted context omitted.

https://github.com/greggh/claude-code.nvim https://github.com/coder/claudecode.nvim

I tried these, and they seem to mainly be opening Claude Code in a pane in Vim, along with commands to open the pane. It’s missing the features added to the Emacs version like open file awareness, access to text selection, and integrated diff for changes. It would be really interesting to see a version which exposes Vim as an MCP. I would love to see Claude Code work on the active file, reading from open buffers, typ…

Hello, I'm the maintainer of the coder/claudecode.nvim plugin.

This plugin does indeed support that functionality. It implements an MCP server using pure Lua and Neovim primitives. It not only notifies Claude Code about the currently open file and selected lines in a file, but also opens diff views whenever Claude Code attempts to make a file change.

Re: Claude Code IDE integration for Emacs

#278

Earlier quoted context omitted.

Sounds wild! What have you built this way? Also as another Emacs user I'm wondering what lesser known packages or elisp snippets do you use? gptel, magit, tramp and org-mode are the usually touted killer features, but what else do you use in the Emacs ecosystem?

Sorry, I saw another commenter ask about the dots but for some reason didn't see this one, all the key files are linked as gists here: https://news.ycombinator.com/item?id=44817968 Let me know if you have any questions (or suggestions for that matter, it's rough in places).

Thanks for sharing!

Re: Claude Code IDE integration for Emacs

#279

Earlier quoted context omitted.

I have a couple more! I take it this is all back-end work? Have you tried out one of the Haskell-y front-end languages? Elm? > Both of these are very (!!!) well complimented by magit, which is so good at AI supervision it seems designed for it, by a genius. Can you expand a little on this point?

I very much recommend just watching some of the great `magit` videos on youtube, but later on when I have time I'll do a little `asciinema` of like, a Claude Code interaction and reviewing / piecewise incorporating the bots changes, so if you check back here tonight or tomorrow latest I'll do a little demo.

Did you get the chance to record this? I'd quite like to see it.

Re: Claude Code IDE integration for Emacs

#280

Earlier quoted context omitted.

> I am not sure I agree with that, but it's definitely not about text editor choice. It's definitely possible but I genuinely don't understand how people work for decades and still move their hand all the way to the arrow keys just go move the cursor to another word. Especially when the solution for this inefficiency is so accessible, existed for decades and is widely available in almost every tool. It's something th…

It’s not the bottleneck of true productivity. It doesn’t matter any more than how close the pedals are together would affect how long it takes me to drive somewhere.

I disagree, the older I get the more aware I am of how impactful even minor friction is. Having "pedals closer together" does in fact make you press the pedals more often especially when you do that thousands of times per day.
Post reply on HN