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, typing Vim motions, and taking advantage of Vim features like find/replace and macros. It would be closer to the real pair programming experience, whereas the read and write experience is slow and disjointed from editing.
The main annoyance is dealing with newlines
" look at neovim at this network socket and get current selection"
This actually works :)
as a long time emacs user i've only recently started really writing my own elisp tools, but claude is pretty good at writing elisp so i've been doing more there (sometimes it loses track of parentheses and you need to fix that, but overall pretty good)
I'll def be trying this out alongside steve yegge's efrit which kicks the emacs up to 11 by letting the agent just write and evaluate arbitrary elisp expressions https://github.com/steveyegge/efrit
It was my observation around 12-18 momths ago that LLMs are weirdly good at elisp (which kicked off all the // hypermodern stuff I'm doing.
I think he's onto something with efrit, I havent gotten it dialed yet but its reaaallyy promising.
I'll keep an eye on this new offering though.
There's also https://github.com/editor-code-assistant/eca-emacs which comes from the author of clojure-lsp, a very popular package within the Clojure community. I'd also been wanting to try it.
For both of the more advanced offerings, I tend to be a little cautious when adopting tools I'm trusting my productivity to. Most ambitious projects need to iron out misc stuff during their 'big bang' phase.
I'm wondering if this project will work. It does feel a shame that it doesn't work with the existing mcp.el package[0], but I never got around to setting that up anyways. I wonder if it's a limitation of the package? or not wanting another dependency?
(in addition I've only really played around with claude code a little because I haven't gotten it to a place where I can make it write code I'd consider acceptable for my day job.)
I wrote a short article about how I configured it there: https://her.esy.fun/posts/0029-ai-assistants-in-doom-emacs-3...
One thing I really appreciate with gptel is that it is very easy to switch from Claude to something else like a local llm (via ollama or gpt4all for example). And the interface will be similar.
Its not that I dislike Cursor, its that I dont have time to put up with its compromises for non-extreme-power-user accessibility. I need an extreme power, cost indifferent, tuned for the margins stack.
That's nothing with a VSCode base that I know about, and I've tried Cline and Roo and Continue and written a bunch MCP servers and I measure it all, not even close.
I bet the neovim people have something just as good.
It's good for what it is but I don't love that I have to change to a whole-ass new editor to get access to the agentic additions, when alternatives that require an API key or a more flexible CLI tool can do a better job.
I’d love to hear more about your workflow if you have time to share!
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.
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?
Let me know if you have any questions (or suggestions for that matter, it's rough in places).
I aspire to be a lot faster than this stuff (I've built faster stuff than this) but this is quite a good library (amazingly good by OSS standards, good stuff in this area is rarely OSS, props to the maintainers): https://github.com/crypto-chassis/ccapi, in particular this library does a really good job of being correct across a lot of surface area, it's serious people doing it, and there are forks of it that use DPDK floating around.
If by who's paying for it you mean the big Anthropic bill? My boss's boss is pretty enlightened about the fact that learning how to use AI well is expensive, so when I'm on a tight schedule I get a pretty forgiving budget for the model fees. It's a pretty serious perk in the sense that it's really expensive to master using these things :)
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?
https://gist.github.com/b7r6/84c6ab80c0b8bd5267b8c436e4d00a8...
https://gist.github.com/b7r6/23cfacbf181c9b0447841c798345a79...
The AI stuff doesn't work without this running:
https://gist.github.com/b7r6/449faab9b5be00867f2e8053c610bdb...
That lets me publish my API vendor keys without issues:
https://gist.github.com/b7r6/fe96bd0cc37d72c1991d84d1984371b...
Slow your roll. Nothing you write will matter in six months.
But as a guy who is a known enemy of the Valley establishment to begin with rebuilding from all that? When I say I'm dead serious, I'm being earnest.
If you don't have a family/community safety net and/or a plugged-in nepo golden age network?
Stack cash on hand like your life depends on it, because it fucking does.
signed:
someone who was broke fifteen years ago and has been stacking cash on hand ever since.
And a shitty job is no guarantee of a shitty room now, you see homeless people still in the Best Buy shirt they were wearing when they got laid off, and Best Buy is nowhere near the worst job.
I thought working hard and being really good at computer stuff was basically some kind of bare minimum job guaranteed, that being free with my money might mean not retiring young. Didn't realize tech employment was war.
Wrong. Won't make that mistake again.
But the short answer is no. Not yet.
I'm pretty happy just letting the standalone agent write to the file and then reloading it in my editor.
Though I wish the agent CLI tools would use something like inotify to notice when I've made a manual change to a file that they've recently written and then do a better job of incorporating that change as feedback to inform future edits.
FWIW, Vim (and presumably emacs) can run terminals as well as do things like ssh and ftp. Though I'm pretty sure the easiest thing to do would just be to use the Ctrl-R pattern in vim and have it send curl requests in a different buffer. As far as I'm aware, all the major LLM platforms have APIs that can be accessed through curl (or any other way you want to to GET/PUT requests). Here's something I found with a quick Google search[0].
So I'm not sure there needs to be "a standard" so much as "can it do http requests?" which is yes. I mean with this I think you can also see it wouldn't be too hard to set up and connect to a LLM hosted on the LAN. Could do it all through ssh
[0] https://arjunaravind.in/blog/using-vim-as-a-http-client/
LSP and TS just make it easier to standardize across editors and languages.
Also, I don't remember the last time when I worked with anyone who writes code and uses Windows.
Anecdotal experiences can lead to a warped understanding of reality; in mine, Windows and non-emacs users are niche.
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.
I use Spacemacs in evil-mode and I found it very frustrating to try and type into the Claude Code text box (often my cursor would be somewhere weird, the terminal emulator just really did not seem to "understand" that I was not in Insert Mode). I wound up deciding that I'd rather just use Claude Code in the terminal. The Claude Code text box is ALSO annoying there, so I often just write out instructions in some file (in emacs) and tell then tell CC to read it.
Does this project have any facilities for authoring prompts in a temporary buffer or something?
I use default emacs keybindings, which are a bit friendlier with this since they're similar to the bash/readline keybindings it uses... but it's still jarring.
I'm not sure there is a rigid enough definition of IDE to say whether Emacs qualifies or not. I think it does by virtue of its extensibility, but I could definitely see a legit argument that it's merely an editor because it doesn't have a lot of the tooling of something more modern. I think what you consider to be an IDE (IntelliJ, VS, etc) is something that didn't exist until modern GUIs. Prior to that, terminal based things like Emacs (or LSE on VMS) were the closest analog.
Not only that - it supports PDFs (I annotate the books and papers in it), SVGs, variable fonts, emojis, even spreadsheets - yup, you can do Excel-like calculations; there are built-in browsers, etc. Besides, you can control music and video playback - useful when watching videos and taking notes, you can extract video transcripts, etc. etc. There even exists (albeit quite primitive) a video editor for Emacs.
Define "more modern"? Language servers, Git integration, refactoring tools, debugging? Emacs has all of those. Sure, VSCode and IntelliJ give you this stuff out of the box, but they can't match Emacs features like editing the same file in multiple ways at once (indirect buffers), instantly checking what any key does, or changing any behavior on the spot. What looks "outdated" about Emacs is actually its openness - while other IDEs hide everything behind pretty buttons, Emacs lets you see and change how everything works. You actually own your tools instead of just using them. In that way, Emacs isn't just modern - it's timeless.
Emacs standing alone on a Linux Kernel
https://web.archive.org/web/20200110131523/http://www.inform...
That joke was dumb from the beginning and has fallen into complete irrelevance years ago - Emacs actually can and does vim better than Vim, GVim, and Neovim, or any vim plugins for other IDEs. I'm saying this with a confidence of a die-hard, experienced vimmer.
Where IDEs impose hierarchical workflows, Emacs says 'no gods, no masters, only defun' It's not a cathedral or a bazaar - it's an infinite commune where every buffer is a consensus decision you make with yourself.
——
¹ - Peter Kropotkin was a Russian aristocrat who said "fuck nobility" and became one of anarchism's main theorists.
So if you want it to be, yes and with a lot of support out of the box these days.
Honestly, the big barrier to entry for Emacs is finding the time to configure it to your liking. The best way is to use it along with your IDE and existing tooling, slowly integrating Emacs into your workflow piece by piece and tinkering with it when you have a bit of time but always with a goal in mind i.e. window (pane in modern vernacular) management, showing symbol documentation in a hoverbox, adding spell checking to comments or inline git blame.
And sure, there are lots of bits that you need to get used to at first, how copy and paste works out of the box without CUA-mode for one, but they're that big of a deal after a short while as some people make them out to be.
I'll say this though, Emacs is like tiling window management, you either love it and extol its virtues everywhere or you look at its proponents like aliens from another galaxy.
(Among other things)
By which I mean you can make your IDE with it, but it's not an out of the box thing, and it'll be bespoke and unique for you.
With LSP and treemacs and company mode, it's a pretty decent IDE. It just requires you to get all the pieces set up the way you want.
I can start extending it on every possible dimension without even having to write any code into a file - I can open a scratch buffer, write some Elisp and evaluate it in-place.
What else can provide a complete environment where one can code, debug, manage version control, read documentation, run terminals, manage projects (I search through Jira in Emacs), and even handle email or browse the web without ever leaving the editor? I'm reading this thread and typing this comment in Emacs, btw.
While modern "IDE"s like IntelliJ or VS Code offer polished, pre-configured experiences for specific languages, Emacs takes integration to a philosophical level where everything shares the same keybindings, configuration language, and conceptual model, making it less of an application that integrates other tools and more of a platform where all tools become native citizens of a unified computing environment.
https://github.com/coder/claudecode.nvim/blob/main/PROTOCOL....
https://github.com/coder/claudecode.nvim/blob/main/ARCHITECT...
In the meantime this delaying didn't stop the non-free alternatives, but it did slow down adoption of the core project. This is attrocious project management that is driving people to non-free software. In the most egregious cases (bzr and CI build farm), it was done only because of his ego and wanting the FSF to matter.
There's an `emacs` community that recognizes the history without being involved in any contemporary sense.
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.
LLM provide an exceptional opportunity for us to free ourselves from these captor interests, but we need to looking to develop them.
RMS has been proven correct on so many things from standard Microsoft behaviour, and planned obsolete to the licensing rug pulls of so called open source projects.
The question is not about stopping non free, that's a ridiculous objective, but if you don't have any principles you are going to have nothing solid to stand on in response to their nefarious and extractive behaviour.
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.
And that's a good thing, for the most part. Someone needs to hold the hard-line stance. It'll never happen, but it pulls things in that direction. We're all free to do what we like and use whatever software we choose, and part of the reason we have that choice is because the hardliners refuse to budge.
It does mean they make unrealistic demands and occasionally hold back useful functionality, but it's better than not having them around.
VS Code on the other hand is designed to fracture [1]. MS can and has given proprietary API access to their blessed tools, forcing others to go through their much less capable extension API, hence the plethora of vscode forks. Even if you had the most motivated, excited group of people wanting to work on the latest and greatest LLM interactions with VS code, they would most likely be forced to fork. On the other hand, it just takes one motivated Elisp dev to implement whatever they want and make any external package they want integrate with it.
Also, I think the derision from the Emacs community may be a bit overblown. I'm constantly seeing AI/LLM related plugins appearing for Emacs and they tend to get decent traction (e.g. https://github.com/karthink/gptel).
The Levy book Hackers has a ehole third of the book about it.
There is some surprise factor at the GPT-3 -> gpt-4-1106 jump for people who know the history of AI generally and who were around a lab during the ImageNet days, but not as much as everyone is acting like.
The last two years are a notable but by no means unprecedented rush towards the next wall. There's even a term for it: AI Summer is short and AI winter is long and its about as predictable as the seasons in Game of Thrones / ASOIAF.
I'm guessing there's a lot of grumbling on the mailing list about non-free AI services. That's fine, you can ignore that. 3rd party modules will provide, and there's nothing core can do about it.
They always have had. It just depends on what people perceive to be advantageous. For me, VSCode's and IntelliJ's closed model for extensibility is a huge downside.
By "closed" I mean - restrictive plugin APIs, sandboxed execution environment, corporate gatekeeping, opaque core, etc.
I don't even try to "shop for more features" anymore, learning Emacs allows me to remain "goal-oriented", and more often than not, it enables me to get the shit done in a far more satisfactory manner. Meanwhile, almost every time I switch to IDEs, I hit some limitations. It's not even "skill-issue" or unfamiliarity, I do remember my days of using IntelliJ, of which I was a devoted user for almost a decade. The way how I solve problems with Emacs, is just not even close.
More and more they've become just another IDE with too-much-to-do. Still one of (the?) best, but as soon as your editor becomes impractical to use to edit a text file... (because it really just likes to work on projects...).
But yeah, emacs remains functional in a way that JetBrains...probably won't. I'm already more than several years behind on their releases because they stopped putting a decent product...
WebStorm was probably the biggest reason why it took me so long to switch to Emacs. My biggest fear was that if I invested in learning Emacs, and at some point I'd inevitably find that something simply couldn't be done in it, and I'd be forced to go back and my idyllic life would be ruined. God, how wrong I was. Not only have I found _everything_ I needed, I actually discovered radically different ways of solving problems.
In the end, turns out one thing jetbrains did right - they have nailed the marketing - I surrendered without resistance. My biggest regret is not trying out Emacs sooner. I wish someone very persuasive showed me things I did not know were possible. That's why I get very vocal about it - kids have zero idea what they'd be missing.
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...
Got some good success with GLM-4.5-Air running locally recently. Still mainly using claude code max though.
https://github.com/yuya373/claude-code-emacs <- it literally implements every feature that every other ones have.
A quick solution I devised is to use bubblewrap to get a fully separate instance of nvim. Something along the lines of
alias lvim "bwrap --bind / / --bind $HOME/.config/{lazy,n}vim --bind $HOME/.local/share/{lazy,n}vim --proc /proc --dev /dev nvim"
I'm on a new MacOS install for $WORK trying to get lsp and ts work with a Typescript/Go repo and after some $PATH wonkiness (my default shell is not the same shell as the one that emacs launches in) got typescript-ls working but gopls is still having issues being downloaded. I haven't spent the hour or two it would probably take to figure out why the in-built downloader can't put gopls in the right place.
I'm curious what emacs users are doing these days. I'm using Zed right now and really enjoying it but it's really hard to give up 20 years of emacs and I do love how emacs can scale from small one-off config file editing to huge projects and I love how configurable it is.
Is neovim better in this space? Should I be learning how to debug elisp better to understand how the commands interact with my environment? I've been using emacs keybindings (in Dvorak at that) for so long I don't know if I'd enjoy the neovim editing experience.
Perhaps if you solve shell issues there once, they will stick.
I'm quite busy outside of work right now so I'll probably take a crack at this in a few weeks, but it's also dismaying how annoying it is to manage all the ts and lsp dependencies to make my projects work, let alone pointing the lsp to use the right package.json or go path or other things. I have no doubt that, in time, I can whack-a-mole the issues down. It does reduce my confidence in changing my environment because of how brittle the stack is. That's what makes me curious about the rest of the ecosystem.
Zed mostly works though I have had to configure it to use project-specific linter configs using somewhat underdocumented settings files. I'm curious if neovim is easier to get working because it's a smaller beast so easier to debug, but I also just don't know if I'd enjoy a switch to few-key modal editing from the chorded emacs style I love.
https://github.com/purcell/exec-path-from-shell
It can extract PATH and other environment variables from your login shell configuration.
I also recognize the author's name because I use their direnv integration package all the time! That one is great, too.
Still using it because of the massive amount of customizations accumulated in a time span close to yours. I'm often tempted to switch, but if I look back, what other editor would have served me for ~20 years, mostly unchanged? I remember writing lots of macros for Visual Studio 6 and then Microsoft revamped the object system of their IDE with .NET. My understanding is that Visual Studio plugins may not work from an IDE version to the next. Yes, customizing Emacs requires time, but so does relearning a new environment every few years.
I do use other editors, however, for things that would require too much time to configure in Emacs, or for which I prefer a GUI interface. For example, at the moment I'm working on a C++ project in Emacs, yet for debugging and a Git GUI I have VSCode open.
>> Is neovim better in this space?
Maybe, because of the bigger use base of NeoVim/Vim.
>> Should I be learning how to debug elisp better to understand how the commands interact with my environment?
Definitely.
>> I've been using emacs keybindings (in Dvorak at that)
Hi, mate! (^_^)
>> for so long I don't know if I'd enjoy the neovim editing experience.
What? No [Neo]Vim user has ever ported Emacs keybinding to Insert Mode? O_o
I'm curious how fluid that is. My experience with Emacs keybindings has been, well, variable to say the least. Maybe the vim-alike folks can make better experiences. Readline's emacs bindings are a bit lacking but still fairly good for day-to-day usage.
Hell yeah, you should. I just don't understand how the heck people would claim to be using Emacs for decades and still not knowing how to use the built-in profiler, edebug, apropos, macro expansion, advising system, indirect buffers, etc.
They would complain how "fickle" Emacs is, without even realizing that they are literally operating a living, breathing, dynamic and malleable system. If there's a car that allows you to assemble some parts onto it and turn it into a submarine while you're still driving it, of course it would require you at least the knowledge of basic troubleshooting and the acceptance that shit may break at any point.
You have no idea how liberating the feeling is when you can pinpoint a problem, launch a gptel buffer and then ask Emacs to write some elisp for a hook or an advising function, you can even try the snippet in-place, without ever moving it anywhere.
These days I don't even try to strive for a "clean" config - it's modular enough and I can relatively easily navigate through it. Whenever I face a problem, I just add some elisp. When something breaks (usually due to upstream changes), I don't even get annoyed. Identifying a problem and finding a workaround doesn't take too long - typically minutes - and it doesn't even happen very often.
The second half of your message is interesting. The first half is needlessly condescending.
While this may sound condesending, I believe it's understandable where the snub is coming from. VSCode doesn't need evangelism - it has become the de facto standard that every programmer is expected to know. Emacs occupies a different position entirely, and when curious newcomers encounter comments like "I used Emacs for 15 years before switching to...", they draw conclusions that may not reflect the full picture. Upon closer examination, these long-time "experts" often reveal they barely engaged with Emacs beyond basic editing - they've never published packages (which is actually far simpler than creating VSCode extensions), never written custom functions, never even added a simple advice for their own needs. This isn't truly "using Emacs"; it's merely dabbling in it.
Unlike conventional tools where years translate to expertise along a predictable curve, Emacs rewards deep engagement over mere time served. When someone who spent years passively using Emacs criticizes it publicly, they inadvertently discourage potential users who might have discovered something transformative. The damage is disproportionate: criticizing VSCode barely makes a dent in its massive user base, but dismissing Emacs can deter the very people who would thrive in its ecosystem - those willing to invest in understanding a tool that becomes an extension of their thinking rather than just another tool.
Therefore, of course I would be confrontational. I honestly have not ever seen an accurate, honest, factual review of Emacs criticism and comparison with other tools in the same space, because simply there isn't any other tool that operates at the same level. Critics compare surface features while missing that Emacs is essentially a different category of software altogether.
Yes I'm familiar with apropos, macros/extensions, advising, indirect buffers, and a lot of stuff. I've just never debugged elisp mostly because I haven't had a hard time just iterating on elisp to make it work and have never bothered debugging packages I've installed. I've put off learning edebug because for the most part I've used the "Lisp debugging" part of my brain on SBCL and Common Lisp. It's just one of those "do I really need to shave this yak?" kind of things and until now it's been no.
Sounds like edebug is the next elisp frontier for me, thanks.
(Btw your comment is a bit condescending sounding but I actually love reading your emacs comments on HN because your enthusiasm for emacs is great.)
> You have no idea how liberating the feeling is when you can pinpoint a problem, launch a gptel buffer and then ask Emacs to write some elisp for a hook or an advising function, you can even try the snippet in-place, without ever moving it anywhere.
Yes absolutely this though. I've been having a lot of fun with gptel and in general I have all sorts of fun bindings that do exactly what I want to do. There's a reason I don't want to give up emacs and it's this ability to write elisp and wrangle text.
> When something breaks (usually due to upstream changes), I don't even get annoyed. Identifying a problem and finding a workaround doesn't take too long - typically minutes - and it doesn't even happen very often.
I'll be honest, my interest in dealing with this kind of thing greatly varies based on what's going on in my life at the time. Sometimes I'll be locked in and go on a deep binge to optimize my environments. Other times I find it very painful. Maintaining an emacs config has always been quite annoying but I put up with it because the power and customizability of the whole thing is unparalleled.
(The fact that an editor like Cursor is a proprietary fork of an open codebase that restricts you to the team's vision is, uh, honestly pretty silly to me. Like why? I can write code can't I? Guess that means I need to maintain configuration but I'd rather do that than use Cursor any day.)
I dunno, I feel it stopped being like that for me long ago. Perhaps I'm just a "tinkerer" and maybe I never even minded improving my setup. But like I said, at some point, my workflow has become purely "goal-oriented" - whenever I see a problem, I either:
- Make a todo list item and forget about it until next time
- Or start writing some Elisp (if the problem is simple enough)
Let me share some practical examples of each.
One day I got annoyed that it was taking me more than a minute to search for my own comment on HN, around some interesting conversations. I made a todo list item. Then at some point I wrote a function, then later I published a package. I can't even tell you how effing nice it feels now - takes me seconds to find relevant stuff.
The other day I was reading a pdf, while taking notes. pdf-tools has this nice feature called pdf-view-themed-minor-mode - it adjusts the colors of the document to the colors of your theme, nicely blending the pdf into your editor. I use it all the time. I also use a package called circadian.el - using Emacs' built-in solar calendar, it adjusts the color theme based on the time of day. So, my color theme changes automatically, but it doesn't get automatically reflected in pdf documents I previously had opened. Not a biggie, I still can do it manually, yet it took me a few minutes to concoct an advising function that runs after (load-theme) and sets the colors in every pdf. Of course, why do something manually that the computer is supposed to figure out without your assistance?
Now, neither pdf-tools maintainers, nor the author of circadian.el know about my customizations. If any of them make some changes that break my beautiful zen fidgets, why would I even get mad about it? I'll try to fix it, and if it takes me longer than three minutes, I'll just remove it altogether and go back to toggling it manually - not a biggie, never was.
That has become my philosophy that probably extends beyond Emacs - my terminal, my browser, my WM, etc. The world is never meant to be perfect for everyone. But you can make it perfect just for you. I learned that it's better to apply ideas that enable you to build your perfect world, than someone else's perception of what _your_ ideal world should be. That's why for an individual programmer, choosing FOSS tools almost always yields better results in the long run. In a team setting that may be a bit difficult, but if you get inventive enough, you can always find workarounds. This is what Emacs taught me that no other tool ever did - the instinct to never settle for the status quo. Whenever something bothers me, I either discover workarounds on the spot or make it a todo item.
There are lots of pre-configured Neovim distributions if you don't want to roll your own, such as LazyVim [1].
There are lots of AI plugins for Neovim [2].
[2]: https://github.com/rockerBOO/awesome-neovim?tab=readme-ov-fi...
Using Emacs for pretty much everything. Org (w/ babel) for most of my notes, blogs, presentations and todo lists. Magit for everything git. Gnus for keeping up with the linux kernel mailing list firehose. LSPs for C, Python, Go, Rust. Tide for typescript. I use aider and aidermacs for my AI pair programming. Haven't tried Claude Code yet but it's on my todo list because everyone raves about it. I even use mastodon.el, and Circe for IRC.
I use macOS native emacs built from source, currently 31.0.50. The largest project I work with is the Linux kernel which I edit remotely using Magit and LSP over TRAMP.
Integrating with a new language ecosystem is a significant amount of work for me because it involves making choices about what packages to configure and how, and which external dependencies to go with (e.g., which LSP server to use). I try to make those choices carefully, and for a lot of projects I touch in only a dabbler in those languages. It takes time to figure out.
But for actually managing external dependencies (LSP servers, linters, static analyzers, etc.), I use Nix (in particular devenv.sh) and direnv so that Emacs doesn't have to download them; it just finds them on the path. I also sometimes configure those tools via Devenv as well, creating an in-repo RC file for them and pointing to it with an appropriate environment variable. Then my configuration lives in source control and the rest of my team can use the same tools regardless of editor choice.
8 years user here so still an emacs noobie, but I switched to nvim two months ago and haven't opened emacs in a month. Just slapped on lazy.vim and have been toggling the different AI tools in LazyExtras.
I do find the ecosystem a lot better in nvim and it seems the community around nvim is more publicly engaged with new AI tooling - check out ThePrimeagen for example.
What I really want is to be able to run something like this locally for, say, less than $2000 in computer hardware. Is this feasible now or any time soon. Anyone out there using agents with local models for coding?
A lot of people are excited about the Qwen3-Coder family of models: https://huggingface.co/collections/Qwen/qwen3-coder-687fc861...
For running locally, there are tools like Ollama and LM Studio. Your hardware needs will fluctuate depending on what size/quantization of model you try to run, but 2k in hardware cost is reasonable for running a lot of models. Some people have good experiences using the M-series Macs, which is probably a good bang-for-buck if you're exclusively interested in inference.
I'd recommend checking out the LocalLlamas subreddit for more: https://www.reddit.com/r/LocalLLaMA/
Getting results on par with big labs isn't feasible, but if you prefer to run everything locally, it is a fun and doable project.
Is this just a fun project for now, or could I actually benefit from it in terms of software production like I do with tools like claude code?
I am interested in carefully tailoring it to specific projects, integrating curated personal notes, external documentation, scientific papers, etc via RAG (this part I've already written), and carefully chosing the tools available to the agent. If I hand tailor the AI agents to each project, can I expect to get something perhaps similar to the performance boost of Claude code for $2000 (USD)?
If not $2000, then how much would I need? I'm pretty sure for something like $75000 I could do this with a large deep seek model locally, and certainly get something very close to claude code, right?
or:
2. https://frame.work/es/en/desktop
3. https://marketplace.nvidia.com/en-us/developer/dgx-spark/ => https://marketplace.nvidia.com/en-us/reservations/ (cheapest is 3k)
The startup I work for has chosen their flavor of AI subscription and its frankly not developer focused. Instead they chose Google because of the productivity tools in the Google App suite.
I want to try Claude Code but the reality is that I don't want to be the martyr that tells my team lead that I want to see if AI can do (parts of) my job for me. It feels pretty sketchy or maybe even completely wrong to use something like this on a company repo I don't own without permissions, so I haven't done it. I suppose I will just have to continue to wonder if the agentic coding services are smoke and mirrors because I somehow don't know anyone who has used them extensively either and I have no clue when I will be able to use one with the strings attached of it being on a free-tier...
I also have to use it via a proxy server I set up to get around the corporate firewall which explicitly blocks it. The company like the results but wouldn't like how I get them..
More corporate ridiculousness
So I subscribe to a new one every month to try out while still shoveling like 150$/mo at Claude cause it's consistently been the best and the one I use the most. Cursor as well has been good for their completion model which surpasses anything else I've tried for inline/multiline/jump completions.
But I've also tried supermaven, codeium/windsurf, copilot, zed. I guess from the company's perspective, a couple hundred bucks a month is well worth the time of keeping us all up to date with ai tooling.
I’m trying to imagine the Venn diagram of “developers adopting agentic coding” and “developers who use emacs as their IDE”.
Of course I’m going to get swarmed with anecdotes, but my intuition is that there’s just not a lot of overlap.
cristea•14h ago
I hope this comes to vim as well!
helsinki•13h ago
benreesman•13h ago
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.
These people are artists, and hacks follow.
edit: My black balance is calculated on a per-display basis with an HSL-space transform from a hero color by the same NixOS module tree that builds the background from it's own source code as SVG and renders it before downsampling it for the specific display it's on. Of like two people helping beta it, both said roughly "using another desktop is like using the screen at the ATM". DHH is doing something similar with Arch, he's not quite as far along but this is the future.
https://cdn.some.pics/b7r6/68936c070fa56.png
https://cdn.some.pics/b7r6/68936d79c607c.png
bevr1337•12h ago
benreesman•11h ago
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...
bevr1337•11h ago
benreesman•11h ago
chaoskanzlerin•8h ago
That sure is a choice of name for your project!
benreesman•5h ago
komali2•3h ago
benreesman•1h ago
But on a lot of displays (including a couple of the ones I use all the time) the panel can't really do it well, and so there are all kinds of hinting and cheats and other workarounds, and so to get perceptual black, you actually wind up cranking the lum up a little, and that's what I've tried to do with the baseline Ono-Sendai Hypermodern blacks, is give a range of options starting from absolute black, and going up incrementally to GitHub "black"/darkest which is a very expertly designed grayscale (their designers on this are world class), but it's light, it's really high to cope with just about any panel.
If you want to try it out, you can pop these codes into whatever way you set colors:
https://gist.github.com/b7r6/581295d8bb905ef598a05fdf2810a07...
The "Ono-Sendai Memphis" grayscale starts at #000000.
anonymid•6h ago