Like LSP and tree-sitter, I think AI coding tools like Claude Code or Aider are very good news for niche editors like Emacs or Vim. Instead of struggling about implementing advanced IDE-like features, they can integrate with these tools relatively easily, and focus on other editing related features that set them apart. In fact, IMO it makes these editors more competitive because they are highly customizable and easier to integrate with these tools.
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.
As someone who have only used Emacs and Vim in the past 10 years, I wish you are right. But according to my observation, 90% of those 38% of developers only use Vim in when they are sshing to the server to update few config files or make simple edits to the scripts. When they do proper programming (like hundreds lines of coding in a project), they switch to other IDEs like VSCode. So yes I personally still consider Vim and Emacs “niche” editors.
It's niche /for development work/. Being used by a developer doesn't make it used for development. Or the most used developing tool would be the toilet.
It's not. I use vim on a daily basis, but all I do with it is writing commit messages. The rest I do with an IDE or different editor. I'm surely not alone with that.
Even I switch to VSCodium when I write Go, for example, because the Go extension is just so good. I use it for medium- and large-sized projects, when I have to navigate through multiple files. There are ways to do it in Vim (I configured it), and Emacs, but sometimes it really is just easier to click since I am already using the mouse for stuff. There are people who never use their mouse, in which case I can imagine they use Emacs or Vim only.
While not going to argue that vim is niche, I don’t think it is. StackExchange surveys are likely highly unrepresentative and lack external validity. I do not believe 40% of developers use vim based on such an unvalidated and likely biased study.
I've been using vim for 10+ years. The only commands I know are for saving, quitting, enabling line numbers and syntax. I'm sure 90% of the people in your statistics are like me.
I have met people who said they use vim for programming and don't know how to use commands like `%s` and `G` to do those basic things. I don't think most people understand how to use vim, and for those cases it's about the same as using any other editor with a find, and arrow keys and delete. That is, about as much an editor as any textarea in a browser.
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 choice of editor is the least consequential thing in one's understanding of "CS" and programming methodologies. On the other hand, using debuggers, profilers, monitoring tooling can have a real impact on how you solve some problems.
> 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 that goes against the spirit of the medium which is all about automation.
> These days I use VSCode and IntelliJ (depending on language) because they do so many things out of the box.
While I don't appreciate the weight of an IDE, the time commitment to create (and maintain!) a config for vim/nvim with LSP, agents, etc., loses out to the relative ease of adding vim-style modal editing to the IDE.
I believe rather my own eyes over a long career than these surveys. It's certainly well below 10% if you don't count being just used for the lack of any alternative (aka sshing)
Not only that but many new editors straigh up ship vim mode now like Zed, Obsidian etc. The main vscode neovim plugin¹ is very big too with over 500k unique installs. Clearly VIM is still widely popular and not going away anytime soon.
Of course it is niche, that survey is quite skewed, and "using" doesn't mean doing development work there, rather than occasionally having to use it when using remote terminals.
I know only one person from my dozens of developer friends and colleagues who is using neovim.
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.
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 have to go for the jugular every day, and that means "fuck the cost" Opus 4 use in `gptel` (though Qwen and K2 are pushing it out of more and more stuff as I learn the quirks, Opus 4 TTFT under load is unusable and when it starts fighting you on clean merge boundaries because its personality vector has been set to "token stingy" its strictly worse).
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.
Can't speak for you friend, but I got my ass kicked through a combination of the hiring freezes and absorbing a bunch of famiku-wide expenses around a nasty bereavement like, right before that and got pretty much wiped out. Having been very well off (to put it mildly) from like, 2010-2023, I was pretty unclear on the fact that going broke is straight up existential now in a way that was not true ten or fifteen years ago. If you've been doing alright for a decade or so, I wouldn't blame you for not knowing that.
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.
I believe you, my situation might have been different. I never had much growing up and never had good jobs until like my mid 20s, I remember it sucking to be broke but not being scary if that makes sense? You could usually find at least a shitty job and even a shitty job could get you some kind of apartment or room even with bad credit. Nice apartments had hard credit checks but there were independent landlords everywhere, so if you didn't mind the occasional drug deal on your block, it was like, workable. Now its all property management companies with what amounts to one computer system and if you don't like it? AirBnB is happy to absorb every last house, room, carboard box, and park bench.
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.
Ditto. Being broke has always been existential, and pretty damn scary even if you had family and other resources you could lean on. Nothing's changed about that, though particular industries/regions may get better or worse.
My 'beef' with Cursor is that the editor is part of the package and you don't really have the same kind of hooks into the agent that you do with Claude Code or similar, which really means you're at the mercy of the Cursor team to prioritise those things on their roadmap. That includes things like the limit of 40 MCP tools that you can only enable globally (and MCP proxies that try to do this dynamically are a bit flakey) - even just using the GitHub MCP blows through that limit because it's all or nothing.
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.
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.
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).
Share your dotemacs/gptel config? I'm not in love with emacs eider integration. Wondering how to put direct editing/control to the model. Still very cludgy with gptel though I've been using it for months
This is the fairly "cut down" one I alluded to without my mixed-results heavyweight AI integration stuff, this is like a gist of my open dev box session so it's got random shit commented out and stuff, but I think most people's config looks like that point in time:
I work for a medium-sized proprietary/discretionary fund. AFAIK the principles trade all kinds of stuff, macro stuff. My current job is tuning up the execution on the cryptocurrency adjacent desk, but not like blockchain stuff, it's somewhere in between OG crypto trading stuff and like Wall St. HFT circa 2006-2010 depending on how you measure, it's in the "kernel bypass matters but FPGAs are still exotic" sort of regime, some of it is legacy REST APIs still but FIX 4.2 SBE and other real finance protocols (and real banks and stuff) are starting to be a part of the ecosystem.
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 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.
I'm sure some other users can give you better answers, but I'm a bit curious what you mean by "standard".
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
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.
I have a similar but opposite experience. Since around 2015 I've mostly been working with people who primarily use Emacs. In 2014 I was the only weird one, then next team about 3-5, then a dozen, then there was a team of a few dozen where only two were using Vim. On my current team also most of the devs are Emacs users. However, a lot of people use Emacs with Evil-mode, so I guess they can be considered vimmers.
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.
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 Real Work involves a JVM. Still do all the git stuff in emacs/magit, though)
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.
> vim and emacs could potentially have a huge advantage.
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.
I went (10 years ago) JetBrains because of emacs. Back then, they were the Kool Kid in town that made emacs-style functionality more accessible.
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...
Oh boy, I was such a jetbrains kiddo, I can't even tell you. I had posters on my wall with keybinding and commands cheat sheets, I knew people working for JetBrains by their names, I talked to them regularly, it almost felt like we were on the same team. I tried to debug and understand plugins, even wanted to develop one, but somehow never got to do that - the hacking mindset of a habitual programmer just wasn't there yet - I kinda went with the status quo - "if IntelliJ doesn't have this feature, maybe I don't even need to know about it..." I've discovered and reported so many bugs on YouTrack, I still receive updates on them, even today - some of them date to 2009, things that JetBrains never even tried to improve since then.
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.
Emacs' advantage comes from its Lisp interpreter core - AI agents can introspect and modify the entire editor state at runtime through the same evaluation mechanisms that users employ, unlike most editors with rigid plugin APIs.
This is true - and a reason I'm not sure about this package. I'll still try it, but I don't think it's the right way forward.
Pretty much the only advantage is that you get access to logic available in the claude code CLI - which in large parts probably already exists in emacs or extensions. On the downside it'll bind you to claude code.
I'm generally using a generic LLM wrapper - emacs has two good ones, gptel and llm. I have both configured, as both are required by some of the extensions I'm using, but currently prefer gptel: It seems to be more advanced, especially when it comes to tool use.
Advantage of that approach is that when you're hitting a wall with one LLM being stupid with one specific issue you can just switch to a different one. Or you can use the same environment with locally hosted LLMs.
Disadvantage is that the IDE/project functionality is not tied up that nicely yet - there are a few attempts (like minuet or evedel), but nothing I really got into.
Currently I'm mostly doing a chat buffer, and the LLM has tools available to inspect and to some extend alter the current state, published here: https://github.com/aard-fi/gptel-tool-library - that works pretty well on a per file basis, and to some extend it can figure out project details, but overall it lacks project info - in part that's a context limitation thing, where that info should be provided as additional context for each instruction (which I assume the CLI is doing).
What this approach also nicely enables is fun experimentations:
- https://github.com/aard-fi/buffer-turtle implements simple turtle graphics in an emacs buffer, and has bindings for the LLM to control the turtle
- https://github.com/aard-fi/arch-installer has the glue to have the LLM interact with a serial port, and some glue (like basic ANSI escape parsing) to make the result look somewhat reasonable in an emacs buffer. That allows it to do stuff like trying to install Arch linux in a VM
Both repos have links to youtube videos with some runs.
I'm happily using https://github.com/stevemolitor/claude-code.el which is a mere terminal wrapper (including a nifty Transient menu). But just by virtue of running inside Emacs you get a lot of power - it didn't take me a lot of effort to create an efficient, customized workflow that felt much more streamlined than my older iTerm usage.
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 tried that for a bit, and bounced back to just using claude code in a terminal. It was a little bit janky in emacs, and didn't have any features that justified not just running a separate terminal window (for me, at the time I checked it out).
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.)
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.
I'm really glad that emacs is integrating modern tooling like LSP and tree-sitter, now Claude Code, but this approach is showing its age. I'm an emacs user of 20 years and honestly it's getting hard to configure everything these days. Claude Code before the IDE integration was actually the easiest thing to get working (since it just worked and then auto-revert-mode keeps my buffers in sync.)
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.
> Should I be learning how to debug elisp better to understand how the commands interact with my environment?
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.
> 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.
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.)
> Maintaining an emacs config has always been quite annoying
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.
> 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.
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.
I think this sort of comment turns people off from Emacs.
Most people don’t want to become experts in the editor. The editor is a means to an end: writing code, writing text, etc. This comment suggests to the new user: if I don’t program Emacs and publish packages in it, I’m not really using it, I’m just dabbling in it. But I don’t want to program the editor, so I shouldn’t use it at all.
I also don’t think the comments you criticize discourage users who would have discovered something transformative. Someone interested in programming their editor isn’t discouraged by someone who complains that Emacs is missing some modern prettiness, or that it’s not popular. There is plenty of Emacs evangelism that will hook those receptive to it.
I would like to balance out your comment by saying: it is just fine to, as you would say, dabble in Emacs. Don’t write advice. Don’t publish packages. Use customize. Don’t write a .emacs. Use the pull-down menus. It is still a delightfully powerful and well-documented editor even if you do none of the “expert” things. The developers have added so many of these features precisely so Emacs is easier to learn and use, and don’t let commenters who call you a dilettante convince you that if you’re not an Emacs Lisp maestro, you shouldn’t bother with Emacs.
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 use it. When someone says something like "I used Emacs for a decade as just a text editor" to me it sounds like: "I had this smartphone for the past two years and used it only to make calls. Not even video - I never bothered to figure out how that works..."
Emacs is a Lisp-based event-loop, with an embedded editor in it. This is of course a "simplification", but that will do. What do you do with a Lisp interpreter? You feed Lisp programs into it. Try writing some Lisp, it's not that hard. Swallow you hubris, swallow your pride - whichever you prefer and stop blaming parenthesis, bad weather, ThePrimeagen's mustache, sanctions or AI. With AI tools these days it may even feel like playing a video game.
You don't need to be "an expert" there are no "experts" in Emacs, there's no "career ladder," progression system, no ranks and shoulder straps, I don't know anyone who gets paid even just a little bit more for simply being good in Emacs - I certainly don't. Use it or not - just don't think of being "a newbie" or becoming "an expert" you either enjoy it or not, whichever it is - it's fine.
And by the way, I personally think I would've loved to witness my kind of evangelism back when I was still a tool, just much younger.
> I'm curious what emacs users are doing these days.
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.
Use-package can even install third party packages automatically. Definitely worth learning. I converted my .emacs a few years ago. I'm using borg[0] to install stuff though because I like git.
Btw, LLMs are actually quite helpful for configuring Emacs, in particular for creating custom functionality..
But yeah, I broke my home Emacs setup somehow so that rust-mode no longer works in some situations. I have my config in git, though, so maybe I'll figure it out!
At least I've started migrating to use use-package for configuration, to bring some structure to the configuration.
Zed does seem rather interesting, but I don't ever see it being as configurable/extensible at runtime as Emacs. I suppose one could always just implement such features into the Zed itself; I presume its code is not too indimidating, given it's a modern code base and not likely to break in unexpected ways.
> I'm curious what emacs users are doing these days.
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.
Yes Nix is also something I've been thinking of diving into with emacs to solve this issue. What's your experience been running Nix on non-Linux targets? I mostly use MacOS and FreeBSD outside of Linux, primarily MacOS.
I've written most of the development environment declarations for my team's projects, which are mostly glue code or IaC in Terraform, Python, Bash (Nix can do some really cool things with Bash scripts[1]), and Ruby, and some Nix packages that we also use to deploy those projects. About half of my team uses Nix on macOS, and the other half uses Nix on Linux (via WSL), and our other deployment targets are all Linux on AWS (some EC2 boxes, some Lambda services, some ECS/Fargate deployments), though not all of those are Nix-based.
There are sometimes small differences, like sometimes a Python package with native dependencies will fail to build in some Linux environments but not on macOS or vice-versa, but generally you don't, even then, need to special-case things by operating system to make them work uniformly.
As for overall support, macOS is a more chaotic and quirky environment: macOS updates break applications or remove APIs more often than Linux updates do, macOS updates nuke configuration files in `/etc`, or blindly steamroll system users (low UIDs), the login shell doesn't manage environment variables or other aspects of the GUI session, etc. These are extra hurdles that Nix has to work around on macOS. But it generally works well and the only real hooks that Nix needs into your environment are some shell scripts that need to be sourced on startup. If you know how to manage your PATH and shell initialization in general, you can do it with Nix. (Additionally, one distributions of Nix itself includes some extra software for managing these hurdles that works pretty well at the cost of a more opinionated and more "invasive" install-- check out "Determinate Nix" if you're interested.) Other than that, it's basically the same as on Linux. Package selection is good, things mostly work the same way.
Nix's support for platforms other than Linux and macOS is less mature. In years past, efforts have waxed and waned, but in the past few years there've been some concerted and persistent efforts to make Nix and Nixpkgs more usable on Windows, NetBSD, and FreeBSD. Even native (e.g., not just cross-compilation from other platforms) support for Windows is actually a thing!
You can also easily set up "remote builders" to local VMs for Linux and FreeBSD
so that you can transparently build packages and environments for those platforms on your Mac, if that's a frequent choice of development platform.
Overall I'd say it's pretty good, but I don't personally know much about the current status of FreeBSD. It looks like there are a few hundred FreeBSD-specific packages in Nixpkgs, and there's also a fork of NixOS based on FreeBSD called NixBSD. Most packages include "platforms = [ unix ];" in their metadata, which means they're at least intended to build for not just Linux and macOS but also FreeBSD, but I don't know if Hydra is building binaries for any FreeBSD platforms. If it's not, then many packages may be untested and have small build problems. My guess is that at worst, Nix on FreeBSD is probably slightly behind where Nix on Linux was when I got into it 7 or 8 years ago. At that time, Nix still felt amazing and very worth it, but certainly required a willingness to learn how to package things and fill in gaps yourself to get the most out of it. Consider dropping by NixOS' Matrix community; I'm sure there's a FreeBSD channel.
--
>> I'm curious what emacs users are doing these days.
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
> 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.
I am truly, to borrow a phrase from another commenter on this post, a "longtime Emacs dabbler". But I use Evil mode everywhere and sometimes use other Emacs bindings in Insert mode where they don't directly conflict with some other Evil binding. It feels more or less harmonious to me, but I started with Evil and I'm not particularly attached to any default Emacs bindings.
If Typescript is a big part of what you need to deal with on a daily basis, then at some point it makes sense just to use VSCode. And BTW, thats totally by design and a part of Microsoft's developer aquisition strategy.
The path pain sounds to me like a job for nix. If a dependency is not ready at hand, the fix should be a single code change in the project, not separate environment fixes for each dev.
I'm running Homebrew's GUI Emacs which inherits from its opening shell. If I run GUI emacs from my shell then it inherits the environment of the shell so that seems to be doing okay.
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.
> I'm curious what emacs users are doing these days.
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.
> 8 years user here so still an emacs noobie, but I switched to nvim
I don't know man, whenever I see comments like this, I just don't get it - there's just no "switching" for me personally to anything, like ever, I just don't even see the possibility for it.
The question that always gets me is like: "were you just using it like ... I don't know to edit text? That's all you've done with it?..."
I have no idea how would I be able to do my things in anything else, whatever that is - Nvim, Sublime, Helix, etc.
- How would I control video playback from my editor while taking notes?
- How would I annotate PDFs?
- Or, create and manage Anki cards - my flashcards are just my notes, they don't require a different medium to exist.
- Or how would I test APIs - I don't need to use stuff like Postman - all my endpoint investigations are in my notes. Documented and perfectly reproducible.
- How would I manage my dotfiles? I use Org-babel for it and it makes my entire system immutable - is it better than Nix? I dunno, it just works and it's simple.
- What would I use for file management? I just wrote a wrapper that uses rsync to move large files around, how would I ever do anything like this in other than Emacs? How would I mark all the files that are over 1GB, older than three months and match a given regexp?
- In Emacs, I can move my cursor to a piece of plain text like "RFC 959", "SAC-28410", or "my-org/some-service#182" and immediately start reading shit - it intelligently recognizes that the first one is an RFC document, another is a Jira ticket and the third one is a Pull-request on GitHub.
- I can type a single query and simultaneously search for it on Wikipedia, Google, YouTube, GitHub, Hacker News or my own browser history, and I wouldn't even know how to do that in something that's not Emacs.
- In Emacs I can type a shell command and pipe results into a buffer, or pipe the content of a buffer to a shell command.
- In Emacs, my color theme changes depending on time of the day, because Emacs has built-in lunar and solar calendars.
- How would I read and manage my email in Helix?
- How would I track time? Clock in/out of tasks, generate time reports, do pomodoros?
- How would I search, browse and read Hacker News and Reddit?
- How would I create presentations?
- How would I test database queries?
- How would I manage Docker containers?
- How would I read man pages?
- How do I translate text?
- And how would I interact with LLMs?
...
Nope, there's no "switching" for me. It's just not possible. My entire life is woven into this text-based operating system. My thoughts, my work, my communications, my entertainment - they all exist as interconnected plain text that I can grep, link, transform, and version control. Every keystroke I've memorized, every workflow I've perfected, every piece of data that references another - it would take years to rebuild this in whatever there might be, and I'd still be left with a pale imitation. Emacs isn't just where I edit text; it's where I live.
I envy your level of emacs knowledge! I did a lot of things in it, but not as many as you: https://blog.calebjay.com/posts/my-emacs-environment/ I really wish I had finished my blog post I'm working on right now about my new life stack that no longer involves emacs, it'd contain all the info I'd like to convey here.
Looking at your list, I guess what it came to for me is that getting an excellent UX for any one of those given tasks is only possible by using a tool made for that job. Probably, I can get a very good experience using Emacs, or maybe even excellent, but it would take a lot of time for me to tweak a plugin or write my won.
Video playback: Are you playing your youtube or jellyfin videos in Emacs? Well, that's pretty cool, I just have a firefox tab open for one or the other, on a second screen. If I want to pause or skip, I `META-l` to that window on my second screen (i3wm) and use vimium bindings or the native player bindings to interact with it.
Annotate PDFs: I don't do this anymore. I used to hand-annotate in various tablets as an experiment, but in the end all my notes got digitized to a note taking application anyway (org mode, previously) so I just highlight things, handwrite notes when needed in a notebook, and then summarize them in a note taking application (or write them there directly).
Anki cards: I used to do this in emacs as well. Now I don't use anki at all anymore. I didn't find any improvement in my life, conversations, or blog posts from memorizing all these facts (and this includes memorizing words in my Mandarin learning journey). Instead all I seemed to be doing was exhausting what little learning energy I had on "the dreaded flashcards." Plus it was tedious to write and maintain them, even though it was happening right there in the same org file I used to take these notes.
I'd be curious to learn more about your API testing setup, that sounds very cool! At work, our API is served via FastAPI and there's swagger docs automatically available that I can browse in a web browser if I want, or I just in nvim `SPC f f` to open a fuzzy file finder and find the model definition I want and look at the endpoint directly, or I can do the same to find the kubb-generated react hook, or typescript model, for the endpoint. For other projects, I guess I browse the API docs in a web browser.
I've never heard of using org-babel for managing dotfiles, that's a cool idea! I just have them in `~/.configs/` which is a git repo that I mirror to a private github repo.
Re: file management: I do the same but just using either `mini-files` in nvim, or, just some combination of gnu tools in a terminal. If I need a script I usually write one in python or bash. Being able to do so in lisp sounds pretty cool, though.
Text under cursor - what modes is that? That's pretty cool. I just browse jira tickets and pull requests in a web browser. I've never found desktop apps, terminal wrappers, etc, to be as good as just whatever a given company is shipping for their webapp (e.g. I tried managing github PRs in magit using that magit-forge thing but didn't find the experience that great compared to github's webapp).
That is a very cool mode you have for searching, I think I saw something like that on reddit once, but my thought on it is the same now as it was then - why wouldn't I do that but on google.com or search.brave.com, both of which already search wikipedia, google, youtube, github, and hacker news? I can type the same into the address bar of my browser and it'll do the same but also search my web history.
Piping shell commands into a buffer is indeed very cool. You know much more about the terminal than me, I can tell. However naively I could just do this `whatever | nvim`, right?
I saw your comment about the color theme change, that's so sick and I admire you for setting that up. For me, just `vscode-default-high-contrast` was fine 100% of the time I had emacs open, or in nvim `kanagawa-dragon` is fine as well. I don't knock you for having a changing color theme, I just don't really see the point for me.
I used to manage my emails in mu4e and it was fine, but after getting fed up with html emails not rendering correctly, or send email failing silently occasionally and not realizing it, or missing emails for some weird reason, I let go and just switched to thunderbird. I miss having 100% keyboard interaction with email, but thunderbird gets it all done reliably: reply-all, CC, BCC, archive, whatever. I may try out mutt one day though.
I used to track time very well in org mode and that is an extremely useful feature. I thought it was very cool to send to-the-minute invoices to my clients. I would generate time reports and have them added to my `org-roam-daily` entries. So much interesting data! Then I realized, for my own journal, it was an overwhelming amount of data that was basically useless to me, and for my clients, they didn't give a shit, they'd pay me either way, so I started just roughly estimating my hours based on start/end times and that was good enough, got me paid basically the same amount, and took me less time and effort. I do keep a hobonichi techo journal where I annotate the week-view with a general overview of what I get up to hour to hour which is nice to keep me on task and make me quickly realize if I am addicted to a new book and spending too much time reading it.
As for searching reddit, I am a recovering reddit addict and don't use it anymore, though I used to just use it in firefox with ad blocker and using reddit's "old" mode. Hacker news I'm also addicted to and try to avoid using it too much, but again, I just use it in a web browser. Increased friction for my addictions is good: I stay logged out of these sites and only log in when I really need to interact for some reason. This is especially great for twitter which I can't even interact with in any way if I'm logged out.
I always thought it was cool that people were creating presentations in org mode, so I tried it once and then went to give a talk on job hunting at a local university. They didn't have a way to plug an arbitrary device into their projector, so they asked me to email them the microsoft slides files, or send them a link to the google drive presentation, and they obviously had no idea how to install emacs. I didn't have that so had to quickly copy my presentation to google. Google slides works 100% of the time at all the talks and presentations I give so I just use that now. My presentations are quite simple so it's not too much trouble.
As for testing database queries, again, what mode are you using? That's very cool. I test them in dbeaver or in psql directly.
Same question for your docker containers. I just use some combination of `docker ps` or editing docker-compose files, alongside netstat, cloudflare, and portainer's web ui.
I read man pages using `man {whatever}`. Out of all the things you've mentioned, this is the one where I'm actually not curious how you do it in emacs, I just want to know why lol. Come on, opening a terminal and typing `man` isn't that big of a deal, surely!
I translate text using the google translate web UI, which easily lets me switch languages, upload images, etc. I didn't know emacs had a mode for this, that's interesting but I can't imagine it to be quite as smooth as the webUI is...
LLM integration in emacs looks very interesting, I'd like to try it. I like that it can actually use claude's ide mode. As far as I know, no nvim plugin can do that yet. However, right now I don't think any IDE integration works as well as the tab-completion proprietary model cursor uses, that lets me just TAB TAB TAB TAB get something done really quickly. I think their agentic mode is ok, I liked the git-style accept/reject changes thing, but I can do the same by doing claude code in a terminal and then just checking the changes in magit, or, now I use lazygit. Or just `git` commands directly. Personally I'm still chasing the dragon from that first Cursor hit. I really don't want to use Cursor but I want to have something with as-good tab completion and nothing in emacs (before) or nvim (now) has come close, but I will be trying the modes mentioned in this thread!
Regarding org mode in general, I now use a combination of a handwritten daily journal, as well as Trilium-next note taking, which I found to just be a more feature-rich and portable experience in the ways I need it to be, whereas org-mode was feature rich in a way that didn't matter to me. Turns out a super-powerful tagging and organization method for my tasks didn't actually help me stay organized or get more tasks done, but a simple yearly, monthly, weekly, and daily task list supported by a handwritten piece of paper work much better for me. No need to know if a task is for work or pleasure or what the GTD context for it is, I can just check my notebook (or trilium daily entry) to see what needs to get done.
I'm not trying to convince you to "switch." I'm envious of how well you've tailored your emacs to yourself - you're the destination I thought I was headed for when I wrote that blog post linked above. I never arrived, which perhaps is sad, but on the other hand, I spent a lot of time doing a lot of other things, which is just life, I guess!
So how did the switch to neovim go? I'm very interested in where you ended up. Please share a summary if a full blog post is too hard!
> I'd be curious to learn more about your API testing setup, that sounds very cool! At work, our API is served via FastAPI and there's swagger docs automatically available that I can browse in a web browser if I want, or I just in nvim `SPC f f` to open a fuzzy file finder and find the model definition I want and look at the endpoint directly, or I can do the same to find the kubb-generated react hook, or typescript model, for the endpoint. For other projects, I guess I browse the API docs in a web browser.
I used restclient for this for a long time and that was great, but recently it got archived. Some of its functions are about to become deprecated so I'm thinking of moving to hurl-mode. I've used hurl a bunch so maybe that's where I'll end up. This is one of those things I don't like about emacs. The ecosystem is small enough where elisp tools just end up abandoned. CLI tools end up being better because their ecosystems are larger.
> I always thought it was cool that people were creating presentations in org mode, so I tried it once and then went to give a talk on job hunting at a local university. They didn't have a way to plug an arbitrary device into their projector, so they asked me to email them the microsoft slides files, or send them a link to the google drive presentation, and they obviously had no idea how to install emacs. I didn't have that so had to quickly copy my presentation to google. Google slides works 100% of the time at all the talks and presentations I give so I just use that now. My presentations are quite simple so it's not too much trouble.
Try generating PDFs of your presentations. I find that this works pretty much everywhere too. Even locked down computers on college campuses can generally just open up the default PDF reader and render your PDF. And if you're just doing text slides with maybe a graphic or two, then a PDF should be easy to generate.
I'm very tempted to switch, or at least try neovim. My reasoning to switch goes something like:
"The core of nvim is small and mostly depends on Unix-ish tools communicating using pipes. These tools tend to be better supported than a lot of sparsely supported elisp that lives in emacs. Moreover it's easier to debug neovim issues because it's a matter of spawning subprocesses and subshells and simply pushing data into/out of pipes."
I'm not sure if this thesis is correct. I may be off-base how much better support nvim actually has and maybe I'm walking into another emacs, in which case I'd stick with emacs. But also, I just love the editing experience of emacs. I love its chorded commands. I love the kill ring (never understood why folks would use cua-mode.) I love the fluency with which you can record macros. I love writing bits of elisp to automate the stuff I need. It's this experience that I'm not sure neovim can replicate, especially modal editing. I'm also a Dvorak typist and vim ergonomics seem very QWERTY-based.
But I'm very curious how well my thoughts stand up to reality.
I can recommend at least trying neovim, but I had a much easier transition than perhaps you will, since I used `evil-mode` in emacs ;) So I've been a primarily modal editor for 8 years, and actually don't remember any of the chorded commands from my initial days learning emacs. I took one thing from that time: putting CTRL where CAPS is, then I installed evil-mode and never looked back.
I will say as someone who was feeling the start of RSI, I do find vim's bindings to be a lot less painful than emacs chorded commands.
But, I don't know if a "switch" is in the cards for you, from what you've said, because of the Dvorak and that you'd be learning vim and modal editing at the same time. As I understand it, dvorak vimmers can either rebind everything to be in "the same place" to maintain the inherent layout comfort of vim, and lose the mnemonics (`dtp` delete to "p"), and then have to deal with a full rebind on top, or, they can rebind nothing to maintain mnemonics and reduce startup cost, but then have the layout be super wonky and un-ergonomic. Neither sound that pleasant to me. You're right, vim bindings are very qwerty focused.
Also I desperately miss the kill-ring and still hit my binding for it. There are "registers" in nvim and I bet I can find some plugin or write something in lua that will let me switch, on paste, between my "most recent yanks," but I haven't learned how to do that yet.
Macros are great in vim, I think just as powerful as emacs. Lua is also very powerful, but of course, nothing beats the fact that Emacs is a REPL of elisp that you can modify on the fly. Nvim so far as I understand it must reload to register LUA changes (you can still run lua to modify buffer contents though).
However, I do believe the nvim community is more talkative than the emacs one, and busier. Maybe this is because more content creators are vim/nvim-forward, than emacs? I know like, 2 emacs youtubers, and 10 vimmers, some of whom are super famous for other stuff unrelated to programming.
I agree with you on focusing more on unix-ish tools and staying in terminal. It's something that attracted me to nvim. I realized I had been learning a lot of basically one ecosystem, emacs, when instead I could be learning tools that are available on any unix-based machine. Of course you can install emacs on anything, even android, but you gotta install it and get it running. Plus I just feel a lot cooler piping things between unix commands :P
Anyway, for me, the transition was fine. I slapped on lazy.vim and have been basically 99% as productive at work as I was with emacs, only making a couple mistakes here and there. I love the default bindings lazy.vim came with and adjusted to them well. If you do want to try it out, I recommend lazy.vim if you're considering trying out one of the nvim ide packages.
> You're right, vim bindings are very qwerty focused.
I can't share my personal experience, because I never tried switching either to Dvorak or Colemak - I never conceived my typing speed to be a bottleneck - I type faster than I can think of words (but that might be because I'm not a native English speaker), but I've been a vim user for a very long time, and thus I've talked to many vimmers. I have heard several stories that switching to another layout wasn't incredibly difficult, but I suppose the experience would be very personal.
> Macros are great in vim, I think just as powerful as emacs.
Not quite. In Emacs, you can not only record and replay macros, they are fully editable entities.
Vim macros mostly are limited to sequential keystrokes, there's no vars, no if/then logic, no loops, there's no prompting for input, no data manipulation. From practical point these don't really matter, but what sets Emacs apart that you can record a keyboard macro and then fully edit the corresponding elisp code it translates to. Which also allows you to embed logic in a macro - you can inject Elisp evaluation directly during macro recording, which in practice allows you to do things like: "Loop through lines until you find a blank one" inside a macro.
> Maybe this is because more content creators are vim/nvim-forward, than emacs?
That might be true, most Emacs users don't even bother sharing their "secret" knowledge. Some interesting bits quietly sit, marinating in private repos for years, sometimes decades without ever making into a package.
One thing you might be missing here - there is a ton of Emacs Lisp out there. GitHub alone contains some enormous amount of Elisp. It's pretty mind blowing - I suspect there's more Elisp in the wild than Common Lisp and Clojure combined. And of course, I don't need to remind you that Elisp is not a general-purpose language. It's made for one and one objective only - to serve as a configuration language for Emacs, it doesn't get used in anything else.
Even with all the current and increasing popularity of Neovim, it will probably take a while to catch up with Emacs in terms of written code and solutions for it. Case in point - Org-mode. It's been around for a long time; it is an incredibly ingenious system. Alas, so many attempts to clone it to work in something else still haven't gotten too far.
Oy vey, I guess I'll have to get more prescriptive than enumerative. I do seriously appreciate your wonderment and the invitation for less emotional and more scholarly discourse.
> getting an excellent UX for any one of those given tasks is only possible by using a tool made for that job.
That's true, but only to a certain extent. You see, when you look at Emacs' pieces individually, it's really difficult to see it as a perfect tool for any job. Emacs isn't the best email client, it certainly doesn't have the best web browser, it isn't the greatest debugging tool for any given programming language, it's not the best version control tool, etc. But that's when you look at each of the features in isolation. What makes Emacs the overall greatest thing is that it has the ability to act like glue, and things can work in harmonious integration, I've spoken about that before. https://news.ycombinator.com/item?id=44131735 "I cannot compare one or multiple selected aspects of Emacs, because in my view that is a pointless mental exercise — I have the holistic comprehension of Emacs features and only can speak about the emergent properties that arise from their integration. To isolate individual features would be like asking a fish to compare water to air - I exist within this environment so completely that I cannot meaningfully separate its components from the unified experience they create."
> it would take a lot of time for me to tweak a plugin or write my own.
It may take a long time regardless of what tools you use. It all boils down to the mastery of a chosen tool. The majority of beginners focus on shiny trinket features and text editing machinery of Emacs instead of reaping the fundamental principal truth about it - Emacs is not really a mere text editor; in fact, it's a kind of Lisp machine with a text editor embedded in it. Once someone understands that, accepts Lisp with all its enormous power and some unavoidable flaws, that fundamentally changes the entire philosophy of using Emacs to accomplish things.
Now, that's all axiomatic inscribed acoustics, let's get down to less theory:
- For video playback control I use mpv.el with some customizations. Turns out mpv player has IPC and can be perfectly controlled from Emacs, I bet Neovim users do that as well. It's nice when taking notes or when I need to review a bunch of videos in a folder. I have a transient I use to play, rewind, speed up, etc., all directly from the current buffer. It's great.
- I use org-noter for annotating PDFs - it's really nice. I just can't read any technical or scholarly sources without taking notes. And these notes are never disconnected from the source - I can always see my notes next to the exact page. I never needed to find a way to actually embed the notes in a way so I can read them on my phone or tablet, but I bet these days it would be just easier to run Emacs - Android lets you and I don't own Apple products anymore.
- > I don't use anki at all anymore
Oh, that's sad, because there is plenty of research done that proves the effectiveness of spaced repetition. Starting from Ebbinghaus and Pimsleur in the beginning-mid of the prior century, to the modern empirical studies - Cepeda, Kornell, Karpicke. Meta-analyses of Dunlosky and Carpenter. There's recent neuroscientific evidence - Smolen, Zhang, Byrne, et al.
What I like about anki-editor that my flashcards are just my notes - I don't need to maintain some special format, somewhere else. These days, I even often generate flashcards using LLMs and sync them to my phone.
- For testing API endpoints I use Org-mode source blocks. For simple queries - ob-http, for data-heavy stuff I use verb.el - what I like about it is that it exposes hooks where I automatically convert json response to Clojure data structures. IMO Clojure is hands-down the best tool for quick data manipulation. I would have a src-block with `:wrap src clojure` in the header, then I can immediately start exploring the data - slicing, dicing, grouping, mapping through it, visualizing it - all without having to send new requests over and over again. I'm pretty sure I can do the same thing with ob-http by advising corresponding functions, but verb.el has public hooks that are well documented, so... Besides, using org-mode source blocks allows me to pipe that data into any other different language - e.g. Python.
... I'm having to split it (HM whines that my comment gotten too long)...
- > I've never heard of using org-babel for managing dotfiles
Oh that technique is just bananas - my entire system is in a single .org file, I'm sorry I can't share it - it contains private stuff and I just never thought about separating and encrypting it, I don't want to accidentally put something in public portion of it. So, I have source blocks with headers such as:
#+begin_src gitconfig :tangle ~/.gitconfig :tangle-mode (identity #o444)
... it contains my gitconfig values
That's quite straightforward, innit? The readonly mode is for so I am not tempted to manually change the file, and prefer making changes in my dotfiles using (org-babel-tangle) command. Then I have another corresponding part of the same file:
You can see that the first part would write to ~/.gitconfig on any system, the second part only does it on Linux, e.g. gpg program path differs.
I have some other tricks like merging only the values I care about with the entire config template, for example for my terminal. Kitty's config template is self-documented, so I'd like to preserve all that, including the values I keep commented out, but I don't want having to include the entire template in my .org file, I only want k/v pairs I modify. What I do is that I run elisp functions on org-babel-tangle-finished-hook, one of them would force Kitty to generate config template, then grab the values from my config and merge them in there. Org-mode files can contain executable elisp, so my single org-mode file is not only declarative, but when needed it also uses imperative instructions. The simplicity of this is ingenious. The only remaining bottleneck for bootstrapping any new machine - VM, EC2, Desktop - Linux and Mac for me is to get a hold of Emacs, cloning my dotfile.org and running org-babel-tangle - usually takes less than two minutes.
- Dired for file management is superb. It's better than anything I ever used before. I have all the trinkets there - icons, vim-style navigation, subtrees, etc. I don't know if you know this already, but Dired stands for "DIRectory EDitor" - you can fully edit your directory structure, recursively, using whichever tools you have in Emacs - multiple cursors and such, you can edit it as if you're editing plain text, and when you commit, it unravels this new structure onto the filesystem - that's just nuts.
- > Text under cursor - what modes is that
For intelligently recognizing patterns in plain-text I use Embark, it's very cool and it's relatively straightforward to add new types and commands recognizing it. If you never used Embark, I highly recommend it - it adds context-aware actions - so if the cursor is at a url, it knows what to do with it. It works great with Consult and Vertico. Another alternative which I have never tried is Hyperbole. I just never explored it, because Embark I guess covers it for me, but maybe there are things there I'm unaware of, it's probably best to expire both.
- For searching on HN I use consult-hn, a package of my own. It's published on MELPA. There's a demo in the readme, where I show how I read HN and Reddit and do some other interesting things, like extracting all urls from a thread.
- > I could just do this `whatever | nvim`, right?
Well, the thing is - when you do that in Eshell, the stuff stays within the Emacs session, buffers remain as part of your workspace, you can append to existing buffers and the result is immediately available for searching, macros, etc. Your command output always remains a first-class citizen in your editing environment.
- For automatic color theme change I use circadian.el. It's a relatively simple package that utilizes Emacs' built-in solar calendar.
- > I used to manage my emails in mu4e
Long ago I got annoyed by inconsistencies in mu4e and switched to notmuch. I don't use email as much anymore as I used to, but notmuch for me works better for mailing list discussions. What I like about using email in Emacs is that I can link to any email in my notes, and can jump to it directly from my notes - which I also don't use a lot, but it's nice to have. I also have some customizations, like finding a given email and opening it in gmail in the browser, or identifying a given email in a mailing list and opening it in the web interface, etc.
- > I used to track time very well in org mode
Yeah, I don't do much of that anymore, except for pomodoros. Pomodoro technique is great and it lets me focus on specific tasks and track the time spent on each, but I have never used it for serious analyses. However, I still can if I ever need to do that.
- > I am a recovering reddit addict and don't use it anymore
Those fuckers shadowbanned my account of many years for no good reason, and now all my previous comments and posts are not publicly available. I tried to send appeal requests for weeks, every single day, but they seem to be going into a void. I used to be very active there, but now I realized those imbeciles just broke the whole idea of what makes Internet, and I don't use it much anymore.
- Presentations in org mode. I don't remember when I had to do it last time, but I had great success with org-reveal. There are a bunch of different ways to create presentations in Org-mode, reveal is just one of them.
- For testing database queries I still use org-mode source blocks, it looks something like:
- For managing Docker there's docker.el, you can also directly explore any given container using TRAMP-mode, you'd just navigate to /docker:container-name:/path/to/file, and that also works for k8s pods
- > Come on, opening a terminal and typing `man` isn't that big of a deal, surely!
Yeah, of course, on the surface it isn't. But you know what I often do (because I can)? I would open a man page in Emacs, using either (man) or (woman) command - typically the second one on Mac. Then, I can select a region of text, narrow my buffer to it and just start typing LLM requests, e.g., "can you explain this part, etc..." That alone makes kind of a big deal for me, not to mention that it's all within the same environment - all the keybindings still work the same, I have imenu, narrowing, etc.
- > I didn't know emacs had a mode for this, that's interesting but I can't imagine it to be quite as smooth as the webUI is...
Ha, you have no idea. First of all, because it's once again, tightly integrated, I can immediately start translating - active region, word-at-point, my killring content, etc. I speak multiple languages and it's not so atypical for me to try to translate things in the midst of typing or reading text - the speed and the efficiency Emacs allows me is beautiful.
But that's not all. Check this out. I'm learning Spanish, alright? So when I want to translate something like "The colonel was born in 1939...", what does GTranslate do? It translates it into "El coronel nació en 1939", and that totally makes sense, right? But guess what? I really needed to see it like this: "El coronel nació en mil novecientos treinta y nueve", because, well, I'm still getting acquainted with the numbers. How would one do it in literally anything else, any other plugin - for Vim, for VSCode, etc? For VSCode, you'd probably have to talk to the maintainer of an existing extension, make PRs, or even make your own. In Vim, you'd have to rewrite an entire function. What did it take me? Like 15 minutes and a few lines of Elisp. Did I have to learn the internals of GTranslate API? No. Did I have to rewrite an entire function that sends the payload there? No! Here's what I did: Using the built-in profile I've identified the function that sends the payload, and advised it. I added an advising function that just before sending the payload, checks the text, finds a pattern, then sends that portion for processing, to the number-to-words function. Guess what? I couldn't even find implementation of such a function in Elisp, and I didn't have time to write my own. I simply delegated the task to the npm package. Hacky? Sure. Stupid? Well, maybe. Yet, it does work. Maybe shit ain't so stupid if thy shit works, eh? Tell me if such simplicity is ever possible in other editors.
- > LLM integration in emacs looks very interesting
Oh, once again, you have no idea. It's just beyond amazing. Using gptel, I can send LLM commands virtually from anywhere - like I'd be typing commands in Eshell and I can just ask an LLM for the proper options for, I dunno, docker-compose, or something. Right there, in-place.
That example alone is very illustrative of what makes Emacs such an amazing tool - the best of everything - you always have access to all the tools you can imagine - I can use spellchecking, thesaurus, translation and LLM while I want to type something in a git commit message, Jira comment, Slack thread, etc.
I'd be talking to someone on the phone, and they'd ask me to spell out some cryptic thing - like a ticket number - no problem, Emacs can help me here, I'd select it, and run (nato-region), it spells it out using NATO alphabet.
I need to quickly figure out the difference between two dates - no worries, built-in calendar has a way for it.
It's just really difficult for me to imagine any scenario, a use case that is text-related and Emacs can't help with for any reason.
Not long ago I wrote a command to OCR the content of my clipboard. Because I didn't want to distract my colleague when he was showing some stuff over Zoom. I didn't want to keep interrupting him with "hey, hold on, can you send me this url?", "wait a minute, I'm taking notes here...", etc.
> I never arrived
It's quite alright, even though it is never a destination but still a journey.
I hope I was able to open your eyes to how empowering Emacs can be. But hey, I'm a die-hard vimmer, I use evil-mode, and I do use Neovim too - it's a fine tool for certain things where Emacs can feel too big and too clunky.
love the ability to add tools to the mcp server - would expect nothing less from emacs :)
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
I'm a long time Yegge fan and follower and while I think he's still in the vibe code honeymoon phase and hasn't had the vibe code hangover yet, his bona fides on emacs are up there with anyones.
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.
Lately I've been seeing a lot of derision from the Emacs community of the consideration for integrating these kinds of tools with Emacs, but I truly think that's much more hurtful than helpful. Although the current development and usage of AI in software development may not closely resemble the techniques used at the time, it seems to me that Emacs' history is inextricably linked to the MIT AI Lab. It feels weird then that people today would shun the inclusion of AI integration into a tool that was produced from such a working group.
The beauty of Emacs though is that it puts the user in full control. There is nothing in the world stopping anyone from modifying anything in Emacs (at least on the Elisp layer), hence packages like this.
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).
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, bzr vs git for emacs code source control, and a CI build farm for emacs. In each one of those cases, he eventually relented and the core project, eventually integrated the non-free alternative years later.
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.
A lot of us are grateful in some abstract way for all the foundational work RMS did both technically and organizationally to preserve what remaining software freedoms we still have, but got off the bus a long time ago. He got really weird and it was on some "no fly zone" shit.
There's an `emacs` community that recognizes the history without being involved in any contemporary sense.
Huh? Open source licenses long predate Stallman. He was, at best, an opportunist who tried to coopt the OSS movement and take it into a kooky ideological niche.
Do you remember how the world got all kinds of weird cults before we got good at identifying cults and the phenomenon of cults? Well, the FSF/GPL is one of those. Many people still need to be deprogrammed.
I never said that Stallman invented open source (he didn't) or that his motives for starting GNU up after the Symbolics fiasco were pure and high-minded (they were petty), or that the contemporary FSF is a force for good (it's not, c.f. glibc dynamic link lock in on a backdoored resolver SONAME chain and Drepper's weird ties).
I said he did a lot of foundational work that's still important today.
I acknowledged a contribution, I didn't beatify him.
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?
That would be a reasonable stance if the difference were in incubating a new project vs excluding functionality from blessing because it interfaces with non free software. The functionality I'm talking about is excluded because of the latter.
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.
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.
The objective is very much to stop non-free software. It always has been. It's not secret - it's explicitly why the FSF exists.
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.
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.
The Emacs community is incredibly diverse. You'll find derision for just about everything if you look for it.
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 weren't called LLMs, but they had neural networks and hardware optimizations for AI and huge teams of people tirelessly labeling stuff to make it look smarter than it is :)
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.
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.
I just tried it. It does not support /ide integration. You can test this by typing /ide in claude code. MCP support is not the same thing as IDE support.
Oh you mean something like active file awareness and selection context? This code seems quite well architected and has websockets well integrated, both features sound like a lunch break’s worth of work if you file a ticket. Other than that, I couldn’t care less about how these capabilities are implemented or whether /ide works.
This is great, and I need it and will use it, but what I need even more is some kind of integration with org mode (or just note taking generally). I found out the hard way that github/copilot deletes conversations after 30 days! So much for building a knowledge base with an AI assistant! I really need something a bit like Goog's `notebookllm` for capturing research, except I'd like to control it locally.
This is awesome. I love emacs and I love integrating AI into my coding work flow.
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?
There's a lot of great work both around supporting memory efficient inference (like on a closer-to-consumer machine), as well as on open source code-focused models.
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.
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?
At Computex here they had a demo running some local model on a cluster of 4 framework desktops. It certainly generated text! Just about one character of it a second.
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...
my biggest issue with agents in neovim or emacs is that I also use emacs and neovim to open or edit sensitive data (like ssh keys, etc) that I don't want to upload to a random LLM.
A quick solution I devised is to use bubblewrap to get a fully separate instance of nvim. Something along the lines of
I believe many of these agents will not operate on files included in a gitignored file, which helps with sensitive assets like .env files. Definitely worth confirming. Either way, don’t open such a file and ask the agent questions about it. It’ll likely process it either way.
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.
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.
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.
Ha, it's a working title. The name I want for what this will become is `straylight v4`, but that name belongs to a friend, and it has to be a worthy successor to earn being called that. :)
Berkeley Mono, which I highly recommend if you're into that sort of thing. It's finnicky, has to be hinted right. But the ligatures and stuff are pretty unrivaled IMHO. I think it's like 100 bucks or something, but I bought it once 10 years ago and the license is still good, so it's got an amortization schedule that makes it a perfectly sensible part of a toolbox for a professional if you like myself find it more legible and pleasant than most alternatives.
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.
Haha, no worries friend. I find it's just totally counter-intuitive how much difference a little configuration makes relative to the cost of the monitor. Even a relatively inexpensive monitor (I've got like a 200 dollar gaming one that's like an Acer Predator clone and it just looked awful but tuned up it looks great, not as good as my real LG panel but still really good). I never really thought of monitors as something that need a bunch of tuning, but it really makes your dollar go further to get the black balance and subpixel hinting and stuff dialed in. For someone like me who can't afford to just go buy an Apple XDR on a whim, it's worth it.
I don't really understand what you're talking about but it sounds cool. Naive question: what's wrong with just #000000 as black? I often change blacks to that in "dark mode" themes that are actually just dark grey. I want BLACK!
Yeah, I also like being able to get real blacks, and certain kinds of panels can do it (I'm not an expert on panels by any means but I think this is one of the bigger selling points of the OLED family of panel designs is that they can turn off a pixel completely, which let's them get an infinite contrast ratio and therefore pure blacks).
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:
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, 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.
Avante - https://github.com/yetone/avante.nvim. Admittedly I haven't had time to keep up with it's changes and as a result have gone back to VS Code + Copilot, but it's very well integrated last I did use it.
I gave Avante a fair try for about a week and my opinion is that it's not really ready for big time yet. Lots of bugs, slow, and cumbersome. Now I just use Claude Code in a separate tmux pane and its great.
I think that’s a decent approach, but doesn’t the performance of a Neovim terminal bother you? It simply does not feel as good as a native terminal pane. It’s not as bad as VSCode’s terminal pane, but it still leaves something to be desired.
I use Neovim + kitty (https://sw.kovidgoyal.net/kitty/conf/) and the performance is phenomenal. Everything is instant. kitty also has a built-in robust layout system so I ended up ditching tmux entirely for it.
Out of curiosity, do you have a good flow for having a file buffer automatically update in response to claude's changes? I'm perpetually needing to remember to `:e!<CR>` to read the updated file.
To offer an anecdote: I've been used to doing `:e!` with vim. I recently finally had a reason to move to nvim... and it's been auto-updating my buffers when I do stuff in `aider`. Very much a, "oh, ok that's nice!" and I haven't dug further.
I’m actually a neovim user already! This makes me worry that my config has something to prevent this behavior (but I hope not, I hate messing with my config)
Can you prompt it? A bit manual, but hey. I wonder if you can script visual selection in Neovim to output full file path plus line number range, for direct copy paste.
Gptel has been working great for me. I'd be interested in checking this out but I only have so much time to set up and test new tools. What features would make it worthwhile to switch from gptel?
You don't "switch" from gptel as this package solves a problem of a different dimension. Gptel is still great for tons of other things, even though it's not suitable for "project context-wise" LLM workflows.
The package define a list of tools that gptel can use to inspect and edit a project. The tools are packaged as a preset so all you have to do is add "@macher" to your prompt to include the tools & update the system directive.
I've tried out a similar project (claude-code.el).
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 have also been using Claude-code.el and agree that the terminal emulators can struggle to integrate well with my regular workflow. What I have been doing is typing my prompt in the scratch buffer or minibuffer and then sending it to Claude with Claude-code-send-command (bound to s in the transient menu). I don’t even need to switch to the Claude code buffer to send it.
I also had the spacemacs golden handcuffs on before I switched to nvim. I worry that while using spacemacs was great for getting me up to speed in a productive emacs environment, it hamstrung my long term understanding and usage of emacs. I'd often have issues like you describe with no idea how to solve it. My white whale was getting all my web dev major modes to respect a .editorconfig.
I tried it and it has similar problems. Claude Code is not a good "citizen" embedded elsewhere as it wants to control the terminal completely.
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 apologize for my ignorance in asking this question but is Emacs considered an IDE? I thought that was a term reserved for large, graphical editors like IntelliJ, Eclipse, or Visual Studio.
Emacs is practically an operating system (the vim joke being that it lacks a good editor). With git integration through magit, LSP server for language integration, and Projectile for project management, it very much acts like an IDE.
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.
Emacs arguably is the only one of the true meaning of "Integrated Development Environment" perhaps more thoroughly than any other editor. When we break down what IDE really means - integrated, development, and environment - Emacs excels in each dimension: it deeply integrates every tool and workflow through its unified Elisp ecosystem rather than merely bundling separate applications;
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.
Queue the old adage ... "Emacs is a great operating system, what it needs is a good editor."
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.
> Emacs doesn't have a lot of the tooling of something more modern
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.
I realize my definition is purely subjective in that I deal with Visual Studio and VS Code almost exclusively and that the VS Code team is instant that they make an editor and not IDE. For me an IDE has graphical tools for building UIs and other workflow items as well as language-specific compilers and tools built in. Like I said, subjective based on my experience (and my experience doesn't include Emacs).
Emacs is a text environment (which can also display images). It can also launch process and have IPC built in. So everything that works with text can be brought into emacs. And often, the only advantages of GUI is animation and aesthetics (to appeal to beginner). Text interfaces can be more productive.
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.
Well, I'd rather call it a PDE (Personal Development Environment)[0]. A term coined in the Neovim community that is pretty apt for Emacs too. Emacs can be pretty minimalist or maximalist depending on your preference, and it can be configured to have IDE-like features, though presented in a different way sometimes.
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.
What? Emacs is in fact a digital anarchism - complete opposite of religion. It's Kropotkin¹ with parentheses - mutual aid through package sharing, no central authority (even RMS can't dictate your config), and every user autonomously creating their own means of production. The 'religion' rhetoric is just subversive humor disguising a radical experiment in computational self-governance.
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.
Well it is already a "graphical" editor. And I would say out of the box it isn't an IDE, but with a couple of common packages added (say a file tree, terminal, code completion, LSP) it looks pretty much identical to any commercial IDE.
It is if you want it to be. I believe Emacs had one of the first GUIs for gdb (GNU Debugger) so it's always been possible. But it's as much or as little as you want it to be really.
an IDE is just what the name says, an integrated development environment. Emacs has robust support for managing projects, compilation, you can debug programs from Emacs including graphically, Magit is exceptional for version control, it's got built-in LSP support now with Eglot, and so on.
So if you want it to be, yes and with a lot of support out of the box these days.
I feel like I still have yet to see any decent answers to this question; Are professional SDE paying for Claude on their own dime, and then logging into their personal account and somehow integrating Claude Code (or other LLMs) into their work repos that way?
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...
Yes I pay for the most expensive Claude sub with my own money and use it at work.
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..
Our company set up some kind of Wise debit card thing where we each get our own number, and they told us "try out any AI tool you want."
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.
Emacs mcp with Claude code driving it? Or is this different as that is what it should be: CC just sending elisp to the mcp and nothing else. Imho that is. Emacs is perfect for it.
I love(d) Emacs a lot a few years ago. Until my job and obligations didn’t leave me much room for tinkering. There is an inverse relationship between tinkering and getting things done. Although LLMs changed the game: These days I leave the tinkering to Claude Code. And can change every aspect of my tools within seconds. No waste of time, max output. But I still moved away. why? Because I believe the Emacs way is wrong. And here’s why: If I‘d do all my computing in Emacs, I‘d miss out on MailMate as a mail app, on Ghostty as my terminal, on Nvim as an editor, Python as my automation language (instead of Elisp where buffer is the data type used most?) and so much more. I like the Unix way: Do one thing, and do it really good: fzf, ripgrep, yazi, lazygit, absolutely awesome apps for the console. And all can communicate with each other via pipes! So I moved away, and never was happier.
It's interesting that AI fulfilled for the common user—through vibe coding—the mission which GNU/FSF could not: the freedom to create any software you want at any time. And it's ironic that of all of the software used to create AIs (like PyTorch and NVIDIA's CUDA stack), none of it was licensed GPL, though plenty of it is OSS. GNU is no longer relevant and, compared to MIT and BSD licenses, really never was. RIP FSF.
Like LSP and tree-sitter, I think AI coding tools like Claude Code or Aider are very good news for niche editors like Emacs or Vim. Instead of struggling about implementing advanced IDE-like features, they can integrate with these tools relatively easily, and focus on other editing related features that set them apart. In fact, IMO it makes these editors more competitive because they are highly customizable and easier to integrate with these tools.
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.
As someone who have only used Emacs and Vim in the past 10 years, I wish you are right. But according to my observation, 90% of those 38% of developers only use Vim in when they are sshing to the server to update few config files or make simple edits to the scripts. When they do proper programming (like hundreds lines of coding in a project), they switch to other IDEs like VSCode. So yes I personally still consider Vim and Emacs “niche” editors.
Yeah, even if that is true, what part of a tool used by close to 40% of developers is niche?
niche /niːʃ,nɪtʃ/ (adjective) denoting products, services, or interests that appeal to a small, specialized section of the population.
It's niche /for development work/. Being used by a developer doesn't make it used for development. Or the most used developing tool would be the toilet.
[flagged]
It's not. I use vim on a daily basis, but all I do with it is writing commit messages. The rest I do with an IDE or different editor. I'm surely not alone with that.
Even I switch to VSCodium when I write Go, for example, because the Go extension is just so good. I use it for medium- and large-sized projects, when I have to navigate through multiple files. There are ways to do it in Vim (I configured it), and Emacs, but sometimes it really is just easier to click since I am already using the mouse for stuff. There are people who never use their mouse, in which case I can imagine they use Emacs or Vim only.
And writing commit messages are to development in the same class as using the restroom?
Judging by the quality of most commit messages - yes.
> Yeah, because I use vim to turn on the shower.
You say that as if it's ridiculous. Isn't there an M-x shower-on command somewhere in Emacs?
While not going to argue that vim is niche, I don’t think it is. StackExchange surveys are likely highly unrepresentative and lack external validity. I do not believe 40% of developers use vim based on such an unvalidated and likely biased study.
Worth noting that a lot of people use those IDEs with vim keys
In rhr group if hundred plus programmers I work with, id estimate less than 5 percent use anything but emacs and vim.
The other tooling feels niche to me.
I've been using vim for 10+ years. The only commands I know are for saving, quitting, enabling line numbers and syntax. I'm sure 90% of the people in your statistics are like me.
I have met people who said they use vim for programming and don't know how to use commands like `%s` and `G` to do those basic things. I don't think most people understand how to use vim, and for those cases it's about the same as using any other editor with a find, and arrow keys and delete. That is, about as much an editor as any textarea in a browser.
If you create a vimrc, even an empty one, I believe you don’t have to enable syntax highlighting manually.
(The existence of a Vim config file disables Vi compatibility mode.)
> 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 choice of editor is the least consequential thing in one's understanding of "CS" and programming methodologies. On the other hand, using debuggers, profilers, monitoring tooling can have a real impact on how you solve some problems.
> 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 that goes against the spirit of the medium which is all about automation.
> These days I use VSCode and IntelliJ (depending on language) because they do so many things out of the box.
While I don't appreciate the weight of an IDE, the time commitment to create (and maintain!) a config for vim/nvim with LSP, agents, etc., loses out to the relative ease of adding vim-style modal editing to the IDE.
I believe rather my own eyes over a long career than these surveys. It's certainly well below 10% if you don't count being just used for the lack of any alternative (aka sshing)
Placing greater weight in our own anecdotes over randomized trials and researches is what gave us some of the worst experiences in recent years.
StackExchange surveys are not “randomized trials” and only qualifies as the lowest quality research.
The group of devs makes all the difference.
In my current role (contracting at a gov dept in a part that uses Rails and PostgreSQL) it's about 30% using vim or neovim.
In the rest of the department where it's .net and Microsoft all the way, the devs likely have never heard of vim.
Based on my eyes, viruses do not exist. I can't see them anywhere. A sample size of "what I see" is not the best foundation for any claims.
If only more people knew about tramp-mode.
Not only that but many new editors straigh up ship vim mode now like Zed, Obsidian etc. The main vscode neovim plugin¹ is very big too with over 500k unique installs. Clearly VIM is still widely popular and not going away anytime soon.
1 - https://github.com/vscode-neovim/vscode-neovim
Most "regular" developers don't actively engage with StackExchange.. I would not believe that statistic at all. And I'm a 7+ years vim user.
Of course it is niche, that survey is quite skewed, and "using" doesn't mean doing development work there, rather than occasionally having to use it when using remote terminals.
I know only one person from my dozens of developer friends and colleagues who is using neovim.
> 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.
According to StackExchange, Emacs is not even a code editor
It's an operating system
Well, in a survey, I‘d say that I’m using it - but mainly for quick configuration file edits on servers where nothing else is installed.
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 have to go for the jugular every day, and that means "fuck the cost" Opus 4 use in `gptel` (though Qwen and K2 are pushing it out of more and more stuff as I learn the quirks, Opus 4 TTFT under load is unusable and when it starts fighting you on clean merge boundaries because its personality vector has been set to "token stingy" its strictly worse).
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.
cannot afford to fuck around, go for the jugular every day
Slow your roll. Nothing you write will matter in six months.
Can't speak for you friend, but I got my ass kicked through a combination of the hiring freezes and absorbing a bunch of famiku-wide expenses around a nasty bereavement like, right before that and got pretty much wiped out. Having been very well off (to put it mildly) from like, 2010-2023, I was pretty unclear on the fact that going broke is straight up existential now in a way that was not true ten or fifteen years ago. If you've been doing alright for a decade or so, I wouldn't blame you for not knowing that.
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.
being broke was absolutely existential fifteen years ago.
signed:
someone who was broke fifteen years ago and has been stacking cash on hand ever since.
I believe you, my situation might have been different. I never had much growing up and never had good jobs until like my mid 20s, I remember it sucking to be broke but not being scary if that makes sense? You could usually find at least a shitty job and even a shitty job could get you some kind of apartment or room even with bad credit. Nice apartments had hard credit checks but there were independent landlords everywhere, so if you didn't mind the occasional drug deal on your block, it was like, workable. Now its all property management companies with what amounts to one computer system and if you don't like it? AirBnB is happy to absorb every last house, room, carboard box, and park bench.
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.
Ditto. Being broke has always been existential, and pretty damn scary even if you had family and other resources you could lean on. Nothing's changed about that, though particular industries/regions may get better or worse.
the code that i am least proud of is the code that has lasted the longest :-)
[dead]
My 'beef' with Cursor is that the editor is part of the package and you don't really have the same kind of hooks into the agent that you do with Claude Code or similar, which really means you're at the mercy of the Cursor team to prioritise those things on their roadmap. That includes things like the limit of 40 MCP tools that you can only enable globally (and MCP proxies that try to do this dynamically are a bit flakey) - even just using the GitHub MCP blows through that limit because it's all or nothing.
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.
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.
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).
Share your dotemacs/gptel config? I'm not in love with emacs eider integration. Wondering how to put direct editing/control to the model. Still very cludgy with gptel though I've been using it for months
This is the fairly "cut down" one I alluded to without my mixed-results heavyweight AI integration stuff, this is like a gist of my open dev box session so it's got random shit commented out and stuff, but I think most people's config looks like that point in time:
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...
Sounds cool. What sort of stuff do you develop, and who's paying for it?
I work for a medium-sized proprietary/discretionary fund. AFAIK the principles trade all kinds of stuff, macro stuff. My current job is tuning up the execution on the cryptocurrency adjacent desk, but not like blockchain stuff, it's somewhere in between OG crypto trading stuff and like Wall St. HFT circa 2006-2010 depending on how you measure, it's in the "kernel bypass matters but FPGAs are still exotic" sort of regime, some of it is legacy REST APIs still but FIX 4.2 SBE and other real finance protocols (and real banks and stuff) are starting to be a part of the ecosystem.
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 :)
Thanks.
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.
it's coming: https://github.com/editor-code-assistant/eca
I'm sure some other users can give you better answers, but I'm a bit curious what you mean by "standard".
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/
No the comment meant that aider and Claude code are CLI programs, so if you can run a terminal in your niche editor, then you are good to go
There's this one: https://eca.dev/
There's a fair bit of discussion about this here: https://github.com/helix-editor/helix/discussions/4037
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.
It's always been that way. Emacs has had advanced IDE-like features for as long as I can remember. Vim too.
LSP and TS just make it easier to standardize across editors and languages.
emacs and vim are not niche, lol
In 15 years of using nothing but emacs, I have never met another emacs user in any of the companies I worked for. plenty of vim but literally 0 emacs
I have a similar but opposite experience. Since around 2015 I've mostly been working with people who primarily use Emacs. In 2014 I was the only weird one, then next team about 3-5, then a dozen, then there was a team of a few dozen where only two were using Vim. On my current team also most of the devs are Emacs users. However, a lot of people use Emacs with Evil-mode, so I guess they can be considered vimmers.
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.
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 Real Work involves a JVM. Still do all the git stuff in emacs/magit, though)
[flagged]
[flagged]
I don’t see a lot of rage bait on HN. Is this bait or just super weird?
Man, if anything you sound like a pretty shit coworker.
[flagged]
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.
> vim and emacs could potentially have a huge advantage.
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.
I went (10 years ago) JetBrains because of emacs. Back then, they were the Kool Kid in town that made emacs-style functionality more accessible.
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...
Oh boy, I was such a jetbrains kiddo, I can't even tell you. I had posters on my wall with keybinding and commands cheat sheets, I knew people working for JetBrains by their names, I talked to them regularly, it almost felt like we were on the same team. I tried to debug and understand plugins, even wanted to develop one, but somehow never got to do that - the hacking mindset of a habitual programmer just wasn't there yet - I kinda went with the status quo - "if IntelliJ doesn't have this feature, maybe I don't even need to know about it..." I've discovered and reported so many bugs on YouTrack, I still receive updates on them, even today - some of them date to 2009, things that JetBrains never even tried to improve since then.
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.
Emacs' advantage comes from its Lisp interpreter core - AI agents can introspect and modify the entire editor state at runtime through the same evaluation mechanisms that users employ, unlike most editors with rigid plugin APIs.
This is true - and a reason I'm not sure about this package. I'll still try it, but I don't think it's the right way forward.
Pretty much the only advantage is that you get access to logic available in the claude code CLI - which in large parts probably already exists in emacs or extensions. On the downside it'll bind you to claude code.
I'm generally using a generic LLM wrapper - emacs has two good ones, gptel and llm. I have both configured, as both are required by some of the extensions I'm using, but currently prefer gptel: It seems to be more advanced, especially when it comes to tool use.
Advantage of that approach is that when you're hitting a wall with one LLM being stupid with one specific issue you can just switch to a different one. Or you can use the same environment with locally hosted LLMs.
Disadvantage is that the IDE/project functionality is not tied up that nicely yet - there are a few attempts (like minuet or evedel), but nothing I really got into.
Currently I'm mostly doing a chat buffer, and the LLM has tools available to inspect and to some extend alter the current state, published here: https://github.com/aard-fi/gptel-tool-library - that works pretty well on a per file basis, and to some extend it can figure out project details, but overall it lacks project info - in part that's a context limitation thing, where that info should be provided as additional context for each instruction (which I assume the CLI is doing).
What this approach also nicely enables is fun experimentations:
- https://github.com/aard-fi/buffer-turtle implements simple turtle graphics in an emacs buffer, and has bindings for the LLM to control the turtle - https://github.com/aard-fi/arch-installer has the glue to have the LLM interact with a serial port, and some glue (like basic ANSI escape parsing) to make the result look somewhat reasonable in an emacs buffer. That allows it to do stuff like trying to install Arch linux in a VM
Both repos have links to youtube videos with some runs.
I'm happily using https://github.com/stevemolitor/claude-code.el which is a mere terminal wrapper (including a nifty Transient menu). But just by virtue of running inside Emacs you get a lot of power - it didn't take me a lot of effort to create an efficient, customized workflow that felt much more streamlined than my older iTerm usage.
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 tried that for a bit, and bounced back to just using claude code in a terminal. It was a little bit janky in emacs, and didn't have any features that justified not just running a separate terminal window (for me, at the time I checked it out).
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.)
[0] https://github.com/lizqwerscott/mcp.el
I personally have great success with gptel + mcp + claude (via copilot due to corporate restrictions)
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.
I'm really glad that emacs is integrating modern tooling like LSP and tree-sitter, now Claude Code, but this approach is showing its age. I'm an emacs user of 20 years and honestly it's getting hard to configure everything these days. Claude Code before the IDE integration was actually the easiest thing to get working (since it just worked and then auto-revert-mode keeps my buffers in sync.)
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.
> Should I be learning how to debug elisp better to understand how the commands interact with my environment?
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.
> 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.
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.)
> Maintaining an emacs config has always been quite annoying
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.
edebug is great! It was way ahead of its time.
> 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.
The second half of your message is interesting. The first half is needlessly condescending.
> 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.
I think this sort of comment turns people off from Emacs.
Most people don’t want to become experts in the editor. The editor is a means to an end: writing code, writing text, etc. This comment suggests to the new user: if I don’t program Emacs and publish packages in it, I’m not really using it, I’m just dabbling in it. But I don’t want to program the editor, so I shouldn’t use it at all.
I also don’t think the comments you criticize discourage users who would have discovered something transformative. Someone interested in programming their editor isn’t discouraged by someone who complains that Emacs is missing some modern prettiness, or that it’s not popular. There is plenty of Emacs evangelism that will hook those receptive to it.
I would like to balance out your comment by saying: it is just fine to, as you would say, dabble in Emacs. Don’t write advice. Don’t publish packages. Use customize. Don’t write a .emacs. Use the pull-down menus. It is still a delightfully powerful and well-documented editor even if you do none of the “expert” things. The developers have added so many of these features precisely so Emacs is easier to learn and use, and don’t let commenters who call you a dilettante convince you that if you’re not an Emacs Lisp maestro, you shouldn’t bother with Emacs.
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 use it. When someone says something like "I used Emacs for a decade as just a text editor" to me it sounds like: "I had this smartphone for the past two years and used it only to make calls. Not even video - I never bothered to figure out how that works..."
Emacs is a Lisp-based event-loop, with an embedded editor in it. This is of course a "simplification", but that will do. What do you do with a Lisp interpreter? You feed Lisp programs into it. Try writing some Lisp, it's not that hard. Swallow you hubris, swallow your pride - whichever you prefer and stop blaming parenthesis, bad weather, ThePrimeagen's mustache, sanctions or AI. With AI tools these days it may even feel like playing a video game.
You don't need to be "an expert" there are no "experts" in Emacs, there's no "career ladder," progression system, no ranks and shoulder straps, I don't know anyone who gets paid even just a little bit more for simply being good in Emacs - I certainly don't. Use it or not - just don't think of being "a newbie" or becoming "an expert" you either enjoy it or not, whichever it is - it's fine.
And by the way, I personally think I would've loved to witness my kind of evangelism back when I was still a tool, just much younger.
Neovim editing has come a long way; you go from barebones (no plugins) to full-blown IDE and everything in between.
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].
[1]: https://www.lazyvim.org/
[2]: https://github.com/rockerBOO/awesome-neovim?tab=readme-ov-fi...
I have no idea why you're being downvoted.
> I'm curious what emacs users are doing these days.
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.
`use-package` has pretty much simplified everything:
Use-package can even install third party packages automatically. Definitely worth learning. I converted my .emacs a few years ago. I'm using borg[0] to install stuff though because I like git.
[0] https://github.com/emacscollective/borg
Btw, LLMs are actually quite helpful for configuring Emacs, in particular for creating custom functionality..
But yeah, I broke my home Emacs setup somehow so that rust-mode no longer works in some situations. I have my config in git, though, so maybe I'll figure it out!
At least I've started migrating to use use-package for configuration, to bring some structure to the configuration.
Zed does seem rather interesting, but I don't ever see it being as configurable/extensible at runtime as Emacs. I suppose one could always just implement such features into the Zed itself; I presume its code is not too indimidating, given it's a modern code base and not likely to break in unexpected ways.
> I'm curious what emacs users are doing these days.
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.
Yes Nix is also something I've been thinking of diving into with emacs to solve this issue. What's your experience been running Nix on non-Linux targets? I mostly use MacOS and FreeBSD outside of Linux, primarily MacOS.
I've written most of the development environment declarations for my team's projects, which are mostly glue code or IaC in Terraform, Python, Bash (Nix can do some really cool things with Bash scripts[1]), and Ruby, and some Nix packages that we also use to deploy those projects. About half of my team uses Nix on macOS, and the other half uses Nix on Linux (via WSL), and our other deployment targets are all Linux on AWS (some EC2 boxes, some Lambda services, some ECS/Fargate deployments), though not all of those are Nix-based.
There are sometimes small differences, like sometimes a Python package with native dependencies will fail to build in some Linux environments but not on macOS or vice-versa, but generally you don't, even then, need to special-case things by operating system to make them work uniformly.
As for overall support, macOS is a more chaotic and quirky environment: macOS updates break applications or remove APIs more often than Linux updates do, macOS updates nuke configuration files in `/etc`, or blindly steamroll system users (low UIDs), the login shell doesn't manage environment variables or other aspects of the GUI session, etc. These are extra hurdles that Nix has to work around on macOS. But it generally works well and the only real hooks that Nix needs into your environment are some shell scripts that need to be sourced on startup. If you know how to manage your PATH and shell initialization in general, you can do it with Nix. (Additionally, one distributions of Nix itself includes some extra software for managing these hurdles that works pretty well at the cost of a more opinionated and more "invasive" install-- check out "Determinate Nix" if you're interested.) Other than that, it's basically the same as on Linux. Package selection is good, things mostly work the same way.
Nix's support for platforms other than Linux and macOS is less mature. In years past, efforts have waxed and waned, but in the past few years there've been some concerted and persistent efforts to make Nix and Nixpkgs more usable on Windows, NetBSD, and FreeBSD. Even native (e.g., not just cross-compilation from other platforms) support for Windows is actually a thing!
You can also easily set up "remote builders" to local VMs for Linux and FreeBSD so that you can transparently build packages and environments for those platforms on your Mac, if that's a frequent choice of development platform.
Overall I'd say it's pretty good, but I don't personally know much about the current status of FreeBSD. It looks like there are a few hundred FreeBSD-specific packages in Nixpkgs, and there's also a fork of NixOS based on FreeBSD called NixBSD. Most packages include "platforms = [ unix ];" in their metadata, which means they're at least intended to build for not just Linux and macOS but also FreeBSD, but I don't know if Hydra is building binaries for any FreeBSD platforms. If it's not, then many packages may be untested and have small build problems. My guess is that at worst, Nix on FreeBSD is probably slightly behind where Nix on Linux was when I got into it 7 or 8 years ago. At that time, Nix still felt amazing and very worth it, but certainly required a willingness to learn how to package things and fill in gaps yourself to get the most out of it. Consider dropping by NixOS' Matrix community; I'm sure there's a FreeBSD channel. --
1: https://github.com/abathur/resholve/
>> I'm curious what emacs users are doing these days.
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
> 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.
I am truly, to borrow a phrase from another commenter on this post, a "longtime Emacs dabbler". But I use Evil mode everywhere and sometimes use other Emacs bindings in Insert mode where they don't directly conflict with some other Evil binding. It feels more or less harmonious to me, but I started with Evil and I'm not particularly attached to any default Emacs bindings.
> Typescript
If Typescript is a big part of what you need to deal with on a daily basis, then at some point it makes sense just to use VSCode. And BTW, thats totally by design and a part of Microsoft's developer aquisition strategy.
Note, Zed now has integration with Claude Code too[0], as an alternative to its own native agent (which funds Zed itself)
[0] https://github.com/jiahaoxiang2000/claude-code-zed
The path pain sounds to me like a job for nix. If a dependency is not ready at hand, the fix should be a single code change in the project, not separate environment fixes for each dev.
I run emacs in docker to manage these issues https://github.com/wwarner/emacs-native-dockerfiles
In macOS, I use the GUI Emacs from https://emacsformacosx.com/
Perhaps if you solve shell issues there once, they will stick.
I'm running Homebrew's GUI Emacs which inherits from its opening shell. If I run GUI emacs from my shell then it inherits the environment of the shell so that seems to be doing okay.
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.
For your particular shell issue:
https://github.com/purcell/exec-path-from-shell
It can extract PATH and other environment variables from your login shell configuration.
!! This seems really nice for macOS users! Less clunky than the "envfile" option Doom Emacs provides for sure.
I also recognize the author's name because I use their direnv integration package all the time! That one is great, too.
> I'm curious what emacs users are doing these days.
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.
> 8 years user here so still an emacs noobie, but I switched to nvim
I don't know man, whenever I see comments like this, I just don't get it - there's just no "switching" for me personally to anything, like ever, I just don't even see the possibility for it.
The question that always gets me is like: "were you just using it like ... I don't know to edit text? That's all you've done with it?..."
I have no idea how would I be able to do my things in anything else, whatever that is - Nvim, Sublime, Helix, etc.
- How would I control video playback from my editor while taking notes?
- How would I annotate PDFs?
- Or, create and manage Anki cards - my flashcards are just my notes, they don't require a different medium to exist.
- Or how would I test APIs - I don't need to use stuff like Postman - all my endpoint investigations are in my notes. Documented and perfectly reproducible.
- How would I manage my dotfiles? I use Org-babel for it and it makes my entire system immutable - is it better than Nix? I dunno, it just works and it's simple.
- What would I use for file management? I just wrote a wrapper that uses rsync to move large files around, how would I ever do anything like this in other than Emacs? How would I mark all the files that are over 1GB, older than three months and match a given regexp?
- In Emacs, I can move my cursor to a piece of plain text like "RFC 959", "SAC-28410", or "my-org/some-service#182" and immediately start reading shit - it intelligently recognizes that the first one is an RFC document, another is a Jira ticket and the third one is a Pull-request on GitHub.
- I can type a single query and simultaneously search for it on Wikipedia, Google, YouTube, GitHub, Hacker News or my own browser history, and I wouldn't even know how to do that in something that's not Emacs.
- In Emacs I can type a shell command and pipe results into a buffer, or pipe the content of a buffer to a shell command.
- In Emacs, my color theme changes depending on time of the day, because Emacs has built-in lunar and solar calendars.
- How would I read and manage my email in Helix?
- How would I track time? Clock in/out of tasks, generate time reports, do pomodoros?
- How would I search, browse and read Hacker News and Reddit?
- How would I create presentations?
- How would I test database queries?
- How would I manage Docker containers?
- How would I read man pages?
- How do I translate text?
- And how would I interact with LLMs?
...
Nope, there's no "switching" for me. It's just not possible. My entire life is woven into this text-based operating system. My thoughts, my work, my communications, my entertainment - they all exist as interconnected plain text that I can grep, link, transform, and version control. Every keystroke I've memorized, every workflow I've perfected, every piece of data that references another - it would take years to rebuild this in whatever there might be, and I'd still be left with a pale imitation. Emacs isn't just where I edit text; it's where I live.
I envy your level of emacs knowledge! I did a lot of things in it, but not as many as you: https://blog.calebjay.com/posts/my-emacs-environment/ I really wish I had finished my blog post I'm working on right now about my new life stack that no longer involves emacs, it'd contain all the info I'd like to convey here.
Looking at your list, I guess what it came to for me is that getting an excellent UX for any one of those given tasks is only possible by using a tool made for that job. Probably, I can get a very good experience using Emacs, or maybe even excellent, but it would take a lot of time for me to tweak a plugin or write my won.
Video playback: Are you playing your youtube or jellyfin videos in Emacs? Well, that's pretty cool, I just have a firefox tab open for one or the other, on a second screen. If I want to pause or skip, I `META-l` to that window on my second screen (i3wm) and use vimium bindings or the native player bindings to interact with it.
Annotate PDFs: I don't do this anymore. I used to hand-annotate in various tablets as an experiment, but in the end all my notes got digitized to a note taking application anyway (org mode, previously) so I just highlight things, handwrite notes when needed in a notebook, and then summarize them in a note taking application (or write them there directly).
Anki cards: I used to do this in emacs as well. Now I don't use anki at all anymore. I didn't find any improvement in my life, conversations, or blog posts from memorizing all these facts (and this includes memorizing words in my Mandarin learning journey). Instead all I seemed to be doing was exhausting what little learning energy I had on "the dreaded flashcards." Plus it was tedious to write and maintain them, even though it was happening right there in the same org file I used to take these notes.
I'd be curious to learn more about your API testing setup, that sounds very cool! At work, our API is served via FastAPI and there's swagger docs automatically available that I can browse in a web browser if I want, or I just in nvim `SPC f f` to open a fuzzy file finder and find the model definition I want and look at the endpoint directly, or I can do the same to find the kubb-generated react hook, or typescript model, for the endpoint. For other projects, I guess I browse the API docs in a web browser.
I've never heard of using org-babel for managing dotfiles, that's a cool idea! I just have them in `~/.configs/` which is a git repo that I mirror to a private github repo.
Re: file management: I do the same but just using either `mini-files` in nvim, or, just some combination of gnu tools in a terminal. If I need a script I usually write one in python or bash. Being able to do so in lisp sounds pretty cool, though.
Text under cursor - what modes is that? That's pretty cool. I just browse jira tickets and pull requests in a web browser. I've never found desktop apps, terminal wrappers, etc, to be as good as just whatever a given company is shipping for their webapp (e.g. I tried managing github PRs in magit using that magit-forge thing but didn't find the experience that great compared to github's webapp).
That is a very cool mode you have for searching, I think I saw something like that on reddit once, but my thought on it is the same now as it was then - why wouldn't I do that but on google.com or search.brave.com, both of which already search wikipedia, google, youtube, github, and hacker news? I can type the same into the address bar of my browser and it'll do the same but also search my web history.
Piping shell commands into a buffer is indeed very cool. You know much more about the terminal than me, I can tell. However naively I could just do this `whatever | nvim`, right?
I saw your comment about the color theme change, that's so sick and I admire you for setting that up. For me, just `vscode-default-high-contrast` was fine 100% of the time I had emacs open, or in nvim `kanagawa-dragon` is fine as well. I don't knock you for having a changing color theme, I just don't really see the point for me.
I used to manage my emails in mu4e and it was fine, but after getting fed up with html emails not rendering correctly, or send email failing silently occasionally and not realizing it, or missing emails for some weird reason, I let go and just switched to thunderbird. I miss having 100% keyboard interaction with email, but thunderbird gets it all done reliably: reply-all, CC, BCC, archive, whatever. I may try out mutt one day though.
I used to track time very well in org mode and that is an extremely useful feature. I thought it was very cool to send to-the-minute invoices to my clients. I would generate time reports and have them added to my `org-roam-daily` entries. So much interesting data! Then I realized, for my own journal, it was an overwhelming amount of data that was basically useless to me, and for my clients, they didn't give a shit, they'd pay me either way, so I started just roughly estimating my hours based on start/end times and that was good enough, got me paid basically the same amount, and took me less time and effort. I do keep a hobonichi techo journal where I annotate the week-view with a general overview of what I get up to hour to hour which is nice to keep me on task and make me quickly realize if I am addicted to a new book and spending too much time reading it.
As for searching reddit, I am a recovering reddit addict and don't use it anymore, though I used to just use it in firefox with ad blocker and using reddit's "old" mode. Hacker news I'm also addicted to and try to avoid using it too much, but again, I just use it in a web browser. Increased friction for my addictions is good: I stay logged out of these sites and only log in when I really need to interact for some reason. This is especially great for twitter which I can't even interact with in any way if I'm logged out.
I always thought it was cool that people were creating presentations in org mode, so I tried it once and then went to give a talk on job hunting at a local university. They didn't have a way to plug an arbitrary device into their projector, so they asked me to email them the microsoft slides files, or send them a link to the google drive presentation, and they obviously had no idea how to install emacs. I didn't have that so had to quickly copy my presentation to google. Google slides works 100% of the time at all the talks and presentations I give so I just use that now. My presentations are quite simple so it's not too much trouble.
As for testing database queries, again, what mode are you using? That's very cool. I test them in dbeaver or in psql directly.
Same question for your docker containers. I just use some combination of `docker ps` or editing docker-compose files, alongside netstat, cloudflare, and portainer's web ui.
I read man pages using `man {whatever}`. Out of all the things you've mentioned, this is the one where I'm actually not curious how you do it in emacs, I just want to know why lol. Come on, opening a terminal and typing `man` isn't that big of a deal, surely!
I translate text using the google translate web UI, which easily lets me switch languages, upload images, etc. I didn't know emacs had a mode for this, that's interesting but I can't imagine it to be quite as smooth as the webUI is...
LLM integration in emacs looks very interesting, I'd like to try it. I like that it can actually use claude's ide mode. As far as I know, no nvim plugin can do that yet. However, right now I don't think any IDE integration works as well as the tab-completion proprietary model cursor uses, that lets me just TAB TAB TAB TAB get something done really quickly. I think their agentic mode is ok, I liked the git-style accept/reject changes thing, but I can do the same by doing claude code in a terminal and then just checking the changes in magit, or, now I use lazygit. Or just `git` commands directly. Personally I'm still chasing the dragon from that first Cursor hit. I really don't want to use Cursor but I want to have something with as-good tab completion and nothing in emacs (before) or nvim (now) has come close, but I will be trying the modes mentioned in this thread!
Regarding org mode in general, I now use a combination of a handwritten daily journal, as well as Trilium-next note taking, which I found to just be a more feature-rich and portable experience in the ways I need it to be, whereas org-mode was feature rich in a way that didn't matter to me. Turns out a super-powerful tagging and organization method for my tasks didn't actually help me stay organized or get more tasks done, but a simple yearly, monthly, weekly, and daily task list supported by a handwritten piece of paper work much better for me. No need to know if a task is for work or pleasure or what the GTD context for it is, I can just check my notebook (or trilium daily entry) to see what needs to get done.
I'm not trying to convince you to "switch." I'm envious of how well you've tailored your emacs to yourself - you're the destination I thought I was headed for when I wrote that blog post linked above. I never arrived, which perhaps is sad, but on the other hand, I spent a lot of time doing a lot of other things, which is just life, I guess!
So how did the switch to neovim go? I'm very interested in where you ended up. Please share a summary if a full blog post is too hard!
> I'd be curious to learn more about your API testing setup, that sounds very cool! At work, our API is served via FastAPI and there's swagger docs automatically available that I can browse in a web browser if I want, or I just in nvim `SPC f f` to open a fuzzy file finder and find the model definition I want and look at the endpoint directly, or I can do the same to find the kubb-generated react hook, or typescript model, for the endpoint. For other projects, I guess I browse the API docs in a web browser.
I used restclient for this for a long time and that was great, but recently it got archived. Some of its functions are about to become deprecated so I'm thinking of moving to hurl-mode. I've used hurl a bunch so maybe that's where I'll end up. This is one of those things I don't like about emacs. The ecosystem is small enough where elisp tools just end up abandoned. CLI tools end up being better because their ecosystems are larger.
> I always thought it was cool that people were creating presentations in org mode, so I tried it once and then went to give a talk on job hunting at a local university. They didn't have a way to plug an arbitrary device into their projector, so they asked me to email them the microsoft slides files, or send them a link to the google drive presentation, and they obviously had no idea how to install emacs. I didn't have that so had to quickly copy my presentation to google. Google slides works 100% of the time at all the talks and presentations I give so I just use that now. My presentations are quite simple so it's not too much trouble.
Try generating PDFs of your presentations. I find that this works pretty much everywhere too. Even locked down computers on college campuses can generally just open up the default PDF reader and render your PDF. And if you're just doing text slides with maybe a graphic or two, then a PDF should be easy to generate.
I'm very tempted to switch, or at least try neovim. My reasoning to switch goes something like:
"The core of nvim is small and mostly depends on Unix-ish tools communicating using pipes. These tools tend to be better supported than a lot of sparsely supported elisp that lives in emacs. Moreover it's easier to debug neovim issues because it's a matter of spawning subprocesses and subshells and simply pushing data into/out of pipes."
I'm not sure if this thesis is correct. I may be off-base how much better support nvim actually has and maybe I'm walking into another emacs, in which case I'd stick with emacs. But also, I just love the editing experience of emacs. I love its chorded commands. I love the kill ring (never understood why folks would use cua-mode.) I love the fluency with which you can record macros. I love writing bits of elisp to automate the stuff I need. It's this experience that I'm not sure neovim can replicate, especially modal editing. I'm also a Dvorak typist and vim ergonomics seem very QWERTY-based.
But I'm very curious how well my thoughts stand up to reality.
Ah, PDF, that would have been smart :P
I can recommend at least trying neovim, but I had a much easier transition than perhaps you will, since I used `evil-mode` in emacs ;) So I've been a primarily modal editor for 8 years, and actually don't remember any of the chorded commands from my initial days learning emacs. I took one thing from that time: putting CTRL where CAPS is, then I installed evil-mode and never looked back.
I will say as someone who was feeling the start of RSI, I do find vim's bindings to be a lot less painful than emacs chorded commands.
But, I don't know if a "switch" is in the cards for you, from what you've said, because of the Dvorak and that you'd be learning vim and modal editing at the same time. As I understand it, dvorak vimmers can either rebind everything to be in "the same place" to maintain the inherent layout comfort of vim, and lose the mnemonics (`dtp` delete to "p"), and then have to deal with a full rebind on top, or, they can rebind nothing to maintain mnemonics and reduce startup cost, but then have the layout be super wonky and un-ergonomic. Neither sound that pleasant to me. You're right, vim bindings are very qwerty focused.
Also I desperately miss the kill-ring and still hit my binding for it. There are "registers" in nvim and I bet I can find some plugin or write something in lua that will let me switch, on paste, between my "most recent yanks," but I haven't learned how to do that yet.
Macros are great in vim, I think just as powerful as emacs. Lua is also very powerful, but of course, nothing beats the fact that Emacs is a REPL of elisp that you can modify on the fly. Nvim so far as I understand it must reload to register LUA changes (you can still run lua to modify buffer contents though).
However, I do believe the nvim community is more talkative than the emacs one, and busier. Maybe this is because more content creators are vim/nvim-forward, than emacs? I know like, 2 emacs youtubers, and 10 vimmers, some of whom are super famous for other stuff unrelated to programming.
I agree with you on focusing more on unix-ish tools and staying in terminal. It's something that attracted me to nvim. I realized I had been learning a lot of basically one ecosystem, emacs, when instead I could be learning tools that are available on any unix-based machine. Of course you can install emacs on anything, even android, but you gotta install it and get it running. Plus I just feel a lot cooler piping things between unix commands :P
Anyway, for me, the transition was fine. I slapped on lazy.vim and have been basically 99% as productive at work as I was with emacs, only making a couple mistakes here and there. I love the default bindings lazy.vim came with and adjusted to them well. If you do want to try it out, I recommend lazy.vim if you're considering trying out one of the nvim ide packages.
> You're right, vim bindings are very qwerty focused.
I can't share my personal experience, because I never tried switching either to Dvorak or Colemak - I never conceived my typing speed to be a bottleneck - I type faster than I can think of words (but that might be because I'm not a native English speaker), but I've been a vim user for a very long time, and thus I've talked to many vimmers. I have heard several stories that switching to another layout wasn't incredibly difficult, but I suppose the experience would be very personal.
> Macros are great in vim, I think just as powerful as emacs.
Not quite. In Emacs, you can not only record and replay macros, they are fully editable entities.
Vim macros mostly are limited to sequential keystrokes, there's no vars, no if/then logic, no loops, there's no prompting for input, no data manipulation. From practical point these don't really matter, but what sets Emacs apart that you can record a keyboard macro and then fully edit the corresponding elisp code it translates to. Which also allows you to embed logic in a macro - you can inject Elisp evaluation directly during macro recording, which in practice allows you to do things like: "Loop through lines until you find a blank one" inside a macro.
> Maybe this is because more content creators are vim/nvim-forward, than emacs?
That might be true, most Emacs users don't even bother sharing their "secret" knowledge. Some interesting bits quietly sit, marinating in private repos for years, sometimes decades without ever making into a package.
One thing you might be missing here - there is a ton of Emacs Lisp out there. GitHub alone contains some enormous amount of Elisp. It's pretty mind blowing - I suspect there's more Elisp in the wild than Common Lisp and Clojure combined. And of course, I don't need to remind you that Elisp is not a general-purpose language. It's made for one and one objective only - to serve as a configuration language for Emacs, it doesn't get used in anything else.
Even with all the current and increasing popularity of Neovim, it will probably take a while to catch up with Emacs in terms of written code and solutions for it. Case in point - Org-mode. It's been around for a long time; it is an incredibly ingenious system. Alas, so many attempts to clone it to work in something else still haven't gotten too far.
Oy vey, I guess I'll have to get more prescriptive than enumerative. I do seriously appreciate your wonderment and the invitation for less emotional and more scholarly discourse.
> getting an excellent UX for any one of those given tasks is only possible by using a tool made for that job.
That's true, but only to a certain extent. You see, when you look at Emacs' pieces individually, it's really difficult to see it as a perfect tool for any job. Emacs isn't the best email client, it certainly doesn't have the best web browser, it isn't the greatest debugging tool for any given programming language, it's not the best version control tool, etc. But that's when you look at each of the features in isolation. What makes Emacs the overall greatest thing is that it has the ability to act like glue, and things can work in harmonious integration, I've spoken about that before. https://news.ycombinator.com/item?id=44131735 "I cannot compare one or multiple selected aspects of Emacs, because in my view that is a pointless mental exercise — I have the holistic comprehension of Emacs features and only can speak about the emergent properties that arise from their integration. To isolate individual features would be like asking a fish to compare water to air - I exist within this environment so completely that I cannot meaningfully separate its components from the unified experience they create."
> it would take a lot of time for me to tweak a plugin or write my own.
It may take a long time regardless of what tools you use. It all boils down to the mastery of a chosen tool. The majority of beginners focus on shiny trinket features and text editing machinery of Emacs instead of reaping the fundamental principal truth about it - Emacs is not really a mere text editor; in fact, it's a kind of Lisp machine with a text editor embedded in it. Once someone understands that, accepts Lisp with all its enormous power and some unavoidable flaws, that fundamentally changes the entire philosophy of using Emacs to accomplish things.
Now, that's all axiomatic inscribed acoustics, let's get down to less theory:
- For video playback control I use mpv.el with some customizations. Turns out mpv player has IPC and can be perfectly controlled from Emacs, I bet Neovim users do that as well. It's nice when taking notes or when I need to review a bunch of videos in a folder. I have a transient I use to play, rewind, speed up, etc., all directly from the current buffer. It's great.
- I use org-noter for annotating PDFs - it's really nice. I just can't read any technical or scholarly sources without taking notes. And these notes are never disconnected from the source - I can always see my notes next to the exact page. I never needed to find a way to actually embed the notes in a way so I can read them on my phone or tablet, but I bet these days it would be just easier to run Emacs - Android lets you and I don't own Apple products anymore.
- > I don't use anki at all anymore
Oh, that's sad, because there is plenty of research done that proves the effectiveness of spaced repetition. Starting from Ebbinghaus and Pimsleur in the beginning-mid of the prior century, to the modern empirical studies - Cepeda, Kornell, Karpicke. Meta-analyses of Dunlosky and Carpenter. There's recent neuroscientific evidence - Smolen, Zhang, Byrne, et al.
What I like about anki-editor that my flashcards are just my notes - I don't need to maintain some special format, somewhere else. These days, I even often generate flashcards using LLMs and sync them to my phone.
- For testing API endpoints I use Org-mode source blocks. For simple queries - ob-http, for data-heavy stuff I use verb.el - what I like about it is that it exposes hooks where I automatically convert json response to Clojure data structures. IMO Clojure is hands-down the best tool for quick data manipulation. I would have a src-block with `:wrap src clojure` in the header, then I can immediately start exploring the data - slicing, dicing, grouping, mapping through it, visualizing it - all without having to send new requests over and over again. I'm pretty sure I can do the same thing with ob-http by advising corresponding functions, but verb.el has public hooks that are well documented, so... Besides, using org-mode source blocks allows me to pipe that data into any other different language - e.g. Python.
... I'm having to split it (HM whines that my comment gotten too long)...
- > I've never heard of using org-babel for managing dotfiles
Oh that technique is just bananas - my entire system is in a single .org file, I'm sorry I can't share it - it contains private stuff and I just never thought about separating and encrypting it, I don't want to accidentally put something in public portion of it. So, I have source blocks with headers such as:
That's quite straightforward, innit? The readonly mode is for so I am not tempted to manually change the file, and prefer making changes in my dotfiles using (org-babel-tangle) command. Then I have another corresponding part of the same file: You can see that the first part would write to ~/.gitconfig on any system, the second part only does it on Linux, e.g. gpg program path differs.I have some other tricks like merging only the values I care about with the entire config template, for example for my terminal. Kitty's config template is self-documented, so I'd like to preserve all that, including the values I keep commented out, but I don't want having to include the entire template in my .org file, I only want k/v pairs I modify. What I do is that I run elisp functions on org-babel-tangle-finished-hook, one of them would force Kitty to generate config template, then grab the values from my config and merge them in there. Org-mode files can contain executable elisp, so my single org-mode file is not only declarative, but when needed it also uses imperative instructions. The simplicity of this is ingenious. The only remaining bottleneck for bootstrapping any new machine - VM, EC2, Desktop - Linux and Mac for me is to get a hold of Emacs, cloning my dotfile.org and running org-babel-tangle - usually takes less than two minutes.
- Dired for file management is superb. It's better than anything I ever used before. I have all the trinkets there - icons, vim-style navigation, subtrees, etc. I don't know if you know this already, but Dired stands for "DIRectory EDitor" - you can fully edit your directory structure, recursively, using whichever tools you have in Emacs - multiple cursors and such, you can edit it as if you're editing plain text, and when you commit, it unravels this new structure onto the filesystem - that's just nuts.
- > Text under cursor - what modes is that
For intelligently recognizing patterns in plain-text I use Embark, it's very cool and it's relatively straightforward to add new types and commands recognizing it. If you never used Embark, I highly recommend it - it adds context-aware actions - so if the cursor is at a url, it knows what to do with it. It works great with Consult and Vertico. Another alternative which I have never tried is Hyperbole. I just never explored it, because Embark I guess covers it for me, but maybe there are things there I'm unaware of, it's probably best to expire both.
- For searching on HN I use consult-hn, a package of my own. It's published on MELPA. There's a demo in the readme, where I show how I read HN and Reddit and do some other interesting things, like extracting all urls from a thread.
- > I could just do this `whatever | nvim`, right?
Well, the thing is - when you do that in Eshell, the stuff stays within the Emacs session, buffers remain as part of your workspace, you can append to existing buffers and the result is immediately available for searching, macros, etc. Your command output always remains a first-class citizen in your editing environment.
- For automatic color theme change I use circadian.el. It's a relatively simple package that utilizes Emacs' built-in solar calendar.
- > I used to manage my emails in mu4e
Long ago I got annoyed by inconsistencies in mu4e and switched to notmuch. I don't use email as much anymore as I used to, but notmuch for me works better for mailing list discussions. What I like about using email in Emacs is that I can link to any email in my notes, and can jump to it directly from my notes - which I also don't use a lot, but it's nice to have. I also have some customizations, like finding a given email and opening it in gmail in the browser, or identifying a given email in a mailing list and opening it in the web interface, etc.
- > I used to track time very well in org mode
Yeah, I don't do much of that anymore, except for pomodoros. Pomodoro technique is great and it lets me focus on specific tasks and track the time spent on each, but I have never used it for serious analyses. However, I still can if I ever need to do that.
- > I am a recovering reddit addict and don't use it anymore
Those fuckers shadowbanned my account of many years for no good reason, and now all my previous comments and posts are not publicly available. I tried to send appeal requests for weeks, every single day, but they seem to be going into a void. I used to be very active there, but now I realized those imbeciles just broke the whole idea of what makes Internet, and I don't use it much anymore.
- Presentations in org mode. I don't remember when I had to do it last time, but I had great success with org-reveal. There are a bunch of different ways to create presentations in Org-mode, reveal is just one of them.
- For testing database queries I still use org-mode source blocks, it looks something like:
- For managing Docker there's docker.el, you can also directly explore any given container using TRAMP-mode, you'd just navigate to /docker:container-name:/path/to/file, and that also works for k8s pods- > Come on, opening a terminal and typing `man` isn't that big of a deal, surely!
Yeah, of course, on the surface it isn't. But you know what I often do (because I can)? I would open a man page in Emacs, using either (man) or (woman) command - typically the second one on Mac. Then, I can select a region of text, narrow my buffer to it and just start typing LLM requests, e.g., "can you explain this part, etc..." That alone makes kind of a big deal for me, not to mention that it's all within the same environment - all the keybindings still work the same, I have imenu, narrowing, etc.
- > I didn't know emacs had a mode for this, that's interesting but I can't imagine it to be quite as smooth as the webUI is...
Ha, you have no idea. First of all, because it's once again, tightly integrated, I can immediately start translating - active region, word-at-point, my killring content, etc. I speak multiple languages and it's not so atypical for me to try to translate things in the midst of typing or reading text - the speed and the efficiency Emacs allows me is beautiful.
But that's not all. Check this out. I'm learning Spanish, alright? So when I want to translate something like "The colonel was born in 1939...", what does GTranslate do? It translates it into "El coronel nació en 1939", and that totally makes sense, right? But guess what? I really needed to see it like this: "El coronel nació en mil novecientos treinta y nueve", because, well, I'm still getting acquainted with the numbers. How would one do it in literally anything else, any other plugin - for Vim, for VSCode, etc? For VSCode, you'd probably have to talk to the maintainer of an existing extension, make PRs, or even make your own. In Vim, you'd have to rewrite an entire function. What did it take me? Like 15 minutes and a few lines of Elisp. Did I have to learn the internals of GTranslate API? No. Did I have to rewrite an entire function that sends the payload there? No! Here's what I did: Using the built-in profile I've identified the function that sends the payload, and advised it. I added an advising function that just before sending the payload, checks the text, finds a pattern, then sends that portion for processing, to the number-to-words function. Guess what? I couldn't even find implementation of such a function in Elisp, and I didn't have time to write my own. I simply delegated the task to the npm package. Hacky? Sure. Stupid? Well, maybe. Yet, it does work. Maybe shit ain't so stupid if thy shit works, eh? Tell me if such simplicity is ever possible in other editors.
- > LLM integration in emacs looks very interesting
Oh, once again, you have no idea. It's just beyond amazing. Using gptel, I can send LLM commands virtually from anywhere - like I'd be typing commands in Eshell and I can just ask an LLM for the proper options for, I dunno, docker-compose, or something. Right there, in-place.
That example alone is very illustrative of what makes Emacs such an amazing tool - the best of everything - you always have access to all the tools you can imagine - I can use spellchecking, thesaurus, translation and LLM while I want to type something in a git commit message, Jira comment, Slack thread, etc.
I'd be talking to someone on the phone, and they'd ask me to spell out some cryptic thing - like a ticket number - no problem, Emacs can help me here, I'd select it, and run (nato-region), it spells it out using NATO alphabet.
I need to quickly figure out the difference between two dates - no worries, built-in calendar has a way for it.
It's just really difficult for me to imagine any scenario, a use case that is text-related and Emacs can't help with for any reason.
Not long ago I wrote a command to OCR the content of my clipboard. Because I didn't want to distract my colleague when he was showing some stuff over Zoom. I didn't want to keep interrupting him with "hey, hold on, can you send me this url?", "wait a minute, I'm taking notes here...", etc.
> I never arrived
It's quite alright, even though it is never a destination but still a journey.
I hope I was able to open your eyes to how empowering Emacs can be. But hey, I'm a die-hard vimmer, I use evil-mode, and I do use Neovim too - it's a fine tool for certain things where Emacs can feel too big and too clunky.
You should really start a youtube channel with Emacs workflows screencasts :)
I have. I just suck at it splendidly and not getting any better https://www.youtube.com/@ilemming
btw, folks, if you have time, join our discussion today at 6PM Central Time https://www.meetup.com/emacsatx
love the ability to add tools to the mcp server - would expect nothing less from emacs :)
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
I'm a long time Yegge fan and follower and while I think he's still in the vibe code honeymoon phase and hasn't had the vibe code hangover yet, his bona fides on emacs are up there with anyones.
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.
Lately I've been seeing a lot of derision from the Emacs community of the consideration for integrating these kinds of tools with Emacs, but I truly think that's much more hurtful than helpful. Although the current development and usage of AI in software development may not closely resemble the techniques used at the time, it seems to me that Emacs' history is inextricably linked to the MIT AI Lab. It feels weird then that people today would shun the inclusion of AI integration into a tool that was produced from such a working group.
The beauty of Emacs though is that it puts the user in full control. There is nothing in the world stopping anyone from modifying anything in Emacs (at least on the Elisp layer), hence packages like this.
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).
[1] https://ghuntley.com/fracture/
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, bzr vs git for emacs code source control, and a CI build farm for emacs. In each one of those cases, he eventually relented and the core project, eventually integrated the non-free alternative years later.
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.
A lot of us are grateful in some abstract way for all the foundational work RMS did both technically and organizationally to preserve what remaining software freedoms we still have, but got off the bus a long time ago. He got really weird and it was on some "no fly zone" shit.
There's an `emacs` community that recognizes the history without being involved in any contemporary sense.
Why did you?
Huh? Open source licenses long predate Stallman. He was, at best, an opportunist who tried to coopt the OSS movement and take it into a kooky ideological niche.
Do you remember how the world got all kinds of weird cults before we got good at identifying cults and the phenomenon of cults? Well, the FSF/GPL is one of those. Many people still need to be deprogrammed.
I never said that Stallman invented open source (he didn't) or that his motives for starting GNU up after the Symbolics fiasco were pure and high-minded (they were petty), or that the contemporary FSF is a force for good (it's not, c.f. glibc dynamic link lock in on a backdoored resolver SONAME chain and Drepper's weird ties).
I said he did a lot of foundational work that's still important today.
I acknowledged a contribution, I didn't beatify him.
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?
It'd be no different than eglot, project.el, etc. Third party packages experiment with stuff, then a stable implementation appears in core.
That would be a reasonable stance if the difference were in incubating a new project vs excluding functionality from blessing because it interfaces with non free software. The functionality I'm talking about is excluded because of the latter.
In that case it'd just live on in Melpa regardless of what the mailing list thinks.
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.
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.
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.
The objective is very much to stop non-free software. It always has been. It's not secret - it's explicitly why the FSF exists.
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.
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.
this is just sad
The Emacs community is incredibly diverse. You'll find derision for just about everything if you look for it.
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.
I didn’t know MIT AI lab was involved in the modern AI boom, that’s interesting
Asionometry has a great video on it: https://youtu.be/sV7C6Ezl35A
The Levy book Hackers has a ehole third of the book about it.
Haven’t got time to watch that but that book seems quite old. Are you sure it talks about LLMs?
They weren't called LLMs, but they had neural networks and hardware optimizations for AI and huge teams of people tirelessly labeling stuff to make it look smarter than it is :)
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.
Give it a try to https://github.com/editor-code-assistant/eca, I'm focusing on make the best tool for ai pair programming in Emacs
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.
I don't know how popular it is but it may be the easiest one to install:
https://melpa.org/#/claude-code
It doesn’t look like that had the /ide integration that Claude-code-ide has
It absolutely does. Give it a try.
I just tried it. It does not support /ide integration. You can test this by typing /ide in claude code. MCP support is not the same thing as IDE support.
Oh you mean something like active file awareness and selection context? This code seems quite well architected and has websockets well integrated, both features sound like a lunch break’s worth of work if you file a ticket. Other than that, I couldn’t care less about how these capabilities are implemented or whether /ide works.
[dead]
This is great, and I need it and will use it, but what I need even more is some kind of integration with org mode (or just note taking generally). I found out the hard way that github/copilot deletes conversations after 30 days! So much for building a knowledge base with an AI assistant! I really need something a bit like Goog's `notebookllm` for capturing research, except I'd like to control it locally.
Try gptel-mode - your chats are in org buffers, and you can save/restore sessions easily. Also plays nicely with mcp.el for more tooling access.
gptel-mode (I have it at C-c L) is great!
There is ob-aider, maybe interesting for you to try.
https://github.com/emacsmirror/ob-aider
Why?
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.
Haha. Yeah I feel they’re exact opposites. Emacs is so DIY/wanting to control your experience and create the perfect tool for you.
I've been using gemini for writing my init.el So many ideas so little time, I'm glad I have the chance
Yes. Emacs with AI coding will be a dream come true to me.
This is awesome. I love emacs and I love integrating AI into my coding work flow.
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?
There's a lot of great work both around supporting memory efficient inference (like on a closer-to-consumer machine), as well as on open source code-focused models.
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.
Awesome. Great info, thanks
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?
gptel supports all sorts of models, including localized ones.
1. MacMini.
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)
At Computex here they had a demo running some local model on a cluster of 4 framework desktops. It certainly generated text! Just about one character of it a second.
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...
OpenCode isn't a fork of Claude Code. It's descended from an independent open-source project that was called "TermAI": https://news.ycombinator.com/item?id=44483338
Note that there are several projects on GitHub that let you proxy an openai compatible server and set it as ANTHROPIC_BASE_URL
Got some good success with GLM-4.5-Air running locally recently. Still mainly using claude code max though.
my biggest issue with agents in neovim or emacs is that I also use emacs and neovim to open or edit sensitive data (like ssh keys, etc) that I don't want to upload to a random LLM.
A quick solution I devised is to use bubblewrap to get a fully separate instance of nvim. Something along the lines of
works great (note: fish alias)I believe many of these agents will not operate on files included in a gitignored file, which helps with sensitive assets like .env files. Definitely worth confirming. Either way, don’t open such a file and ask the agent questions about it. It’ll likely process it either way.
gemini CLI won't, but will if you ask it to.. so what are the guaranteed one of it's internal thinking steps doesn't do the same?
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.
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
>stellarwind
That sure is a choice of name for your project!
Ha, it's a working title. The name I want for what this will become is `straylight v4`, but that name belongs to a friend, and it has to be a worthy successor to earn being called that. :)
What's that font ?
Berkeley Mono, which I highly recommend if you're into that sort of thing. It's finnicky, has to be hinted right. But the ligatures and stuff are pretty unrivaled IMHO. I think it's like 100 bucks or something, but I bought it once 10 years ago and the license is still good, so it's got an amortization schedule that makes it a perfectly sensible part of a toolbox for a professional if you like myself find it more legible and pleasant than most alternatives.
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...
Thank you for clarifying. I opened that screenshot prepared to be amazed by blackness... My mistake ;)
Haha, no worries friend. I find it's just totally counter-intuitive how much difference a little configuration makes relative to the cost of the monitor. Even a relatively inexpensive monitor (I've got like a 200 dollar gaming one that's like an Acer Predator clone and it just looked awful but tuned up it looks great, not as good as my real LG panel but still really good). I never really thought of monitors as something that need a bunch of tuning, but it really makes your dollar go further to get the black balance and subpixel hinting and stuff dialed in. For someone like me who can't afford to just go buy an Apple XDR on a whim, it's worth it.
I don't really understand what you're talking about but it sounds cool. Naive question: what's wrong with just #000000 as black? I often change blacks to that in "dark mode" themes that are actually just dark grey. I want BLACK!
Yeah, I also like being able to get real blacks, and certain kinds of panels can do it (I'm not an expert on panels by any means but I think this is one of the bigger selling points of the OLED family of panel designs is that they can turn off a pixel completely, which let's them get an infinite contrast ratio and therefore pure blacks).
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.
It’s more common that they lead technological advancements in IDEs, not follow. Neovim in particular.
magenta nvim implements a really nice integration of coding agents.
Anyone have good results with something similar for Neovim?
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, 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.
I have tried the CodeCompanion plugin and had good results. I don't use it super extensively but it's nice when I decide to try it.
Avante - https://github.com/yetone/avante.nvim. Admittedly I haven't had time to keep up with it's changes and as a result have gone back to VS Code + Copilot, but it's very well integrated last I did use it.
I gave Avante a fair try for about a week and my opinion is that it's not really ready for big time yet. Lots of bugs, slow, and cumbersome. Now I just use Claude Code in a separate tmux pane and its great.
I just like having a neovim terminal open with claude code open
I think that’s a decent approach, but doesn’t the performance of a Neovim terminal bother you? It simply does not feel as good as a native terminal pane. It’s not as bad as VSCode’s terminal pane, but it still leaves something to be desired.
I use Neovim + kitty (https://sw.kovidgoyal.net/kitty/conf/) and the performance is phenomenal. Everything is instant. kitty also has a built-in robust layout system so I ended up ditching tmux entirely for it.
Just use tmux and split windows
I have never noticed any problem...
The main annoyance is dealing with newlines
I've noticed no problems, and I'm usually pretty controlling about performance- what am I missing?
Out of curiosity, do you have a good flow for having a file buffer automatically update in response to claude's changes? I'm perpetually needing to remember to `:e!<CR>` to read the updated file.
To offer an anecdote: I've been used to doing `:e!` with vim. I recently finally had a reason to move to nvim... and it's been auto-updating my buffers when I do stuff in `aider`. Very much a, "oh, ok that's nice!" and I haven't dug further.
I’m actually a neovim user already! This makes me worry that my config has something to prevent this behavior (but I hope not, I hate messing with my config)
:help 'autoread' (I think)
There is a vim setting to automatically load changes from disk. I can’t remember name of the option right now, but it should be an easy lookup.
they how do you say. look at these lines of code to claude?
I just say "look in file.py at lines 20-30" or "See in function FooBar where we foo the bar".
i guess thats a bit of typing and then claude has to do a grep/find to figure out what you are talking about.
Can you prompt it? A bit manual, but hey. I wonder if you can script visual selection in Neovim to output full file path plus line number range, for direct copy paste.
you can start neomvim with a network ( neovim --listen) socket and tell calude
" look at neovim at this network socket and get current selection"
This actually works :)
magenta nvim
A hn post getting more upvotes than it got stars on github speaks volumes about upvote intent
Gptel has been working great for me. I'd be interested in checking this out but I only have so much time to set up and test new tools. What features would make it worthwhile to switch from gptel?
You don't "switch" from gptel as this package solves a problem of a different dimension. Gptel is still great for tons of other things, even though it's not suitable for "project context-wise" LLM workflows.
I am using macher for small edits on a codebase with gptel: https://github.com/kmontag/macher
The package define a list of tools that gptel can use to inspect and edit a project. The tools are packaged as a preset so all you have to do is add "@macher" to your prompt to include the tools & update the system directive.
I've tried out a similar project (claude-code.el).
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 have also been using Claude-code.el and agree that the terminal emulators can struggle to integrate well with my regular workflow. What I have been doing is typing my prompt in the scratch buffer or minibuffer and then sending it to Claude with Claude-code-send-command (bound to s in the transient menu). I don’t even need to switch to the Claude code buffer to send it.
I think I basically had the same experience: https://news.ycombinator.com/item?id=44813189
I also had the spacemacs golden handcuffs on before I switched to nvim. I worry that while using spacemacs was great for getting me up to speed in a productive emacs environment, it hamstrung my long term understanding and usage of emacs. I'd often have issues like you describe with no idea how to solve it. My white whale was getting all my web dev major modes to respect a .editorconfig.
I tried it and it has similar problems. Claude Code is not a good "citizen" embedded elsewhere as it wants to control the terminal completely.
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 apologize for my ignorance in asking this question but is Emacs considered an IDE? I thought that was a term reserved for large, graphical editors like IntelliJ, Eclipse, or Visual Studio.
Emacs is practically an operating system (the vim joke being that it lacks a good editor). With git integration through magit, LSP server for language integration, and Projectile for project management, it very much acts like an IDE.
Emacs as PID 1
Emacs standing alone on a Linux Kernel
https://web.archive.org/web/20200110131523/http://www.inform...
> the vim joke being that it lacks a good editor
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.
It has a great editor - evil-mode!
Emacs arguably is the only one of the true meaning of "Integrated Development Environment" perhaps more thoroughly than any other editor. When we break down what IDE really means - integrated, development, and environment - Emacs excels in each dimension: it deeply integrates every tool and workflow through its unified Elisp ecosystem rather than merely bundling separate applications;
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.
Queue the old adage ... "Emacs is a great operating system, what it needs is a good editor."
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.
> Emacs doesn't have a lot of the tooling of something more modern
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.
I realize my definition is purely subjective in that I deal with Visual Studio and VS Code almost exclusively and that the VS Code team is instant that they make an editor and not IDE. For me an IDE has graphical tools for building UIs and other workflow items as well as language-specific compilers and tools built in. Like I said, subjective based on my experience (and my experience doesn't include Emacs).
Emacs is a text environment (which can also display images). It can also launch process and have IPC built in. So everything that works with text can be brought into emacs. And often, the only advantages of GUI is animation and aesthetics (to appeal to beginner). Text interfaces can be more productive.
> which can also display images
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.
"Cue"
A pro tip - add a clause in your LLM prompt to randomly misspell words, so people can't blame you for an aislopper. :)
Well, I'd rather call it a PDE (Personal Development Environment)[0]. A term coined in the Neovim community that is pretty apt for Emacs too. Emacs can be pretty minimalist or maximalist depending on your preference, and it can be configured to have IDE-like features, though presented in a different way sometimes.
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.
[0]: https://www.youtube.com/watch?v=QMVIJhC9Veg
It's not an IDE: it's a religion.
What? Emacs is in fact a digital anarchism - complete opposite of religion. It's Kropotkin¹ with parentheses - mutual aid through package sharing, no central authority (even RMS can't dictate your config), and every user autonomously creating their own means of production. The 'religion' rhetoric is just subversive humor disguising a radical experiment in computational self-governance.
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.
Emacs is large and graphical. I'm not sure why the myth persists that Emacs is the same category of thing as vim; it's really not.
Well similarly opposite "myth" persists that Emacs (unlike Vim) is a non-modal editor. It really is a modal one.
Well it is already a "graphical" editor. And I would say out of the box it isn't an IDE, but with a couple of common packages added (say a file tree, terminal, code completion, LSP) it looks pretty much identical to any commercial IDE.
Emacs is an IDE construction kit.
(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.
It is if you want it to be. I believe Emacs had one of the first GUIs for gdb (GNU Debugger) so it's always been possible. But it's as much or as little as you want it to be really.
I think its just using claude code terminology of "IDE integration" . not implying that emacs is an IDE.
an IDE is just what the name says, an integrated development environment. Emacs has robust support for managing projects, compilation, you can debug programs from Emacs including graphically, Magit is exceptional for version control, it's got built-in LSP support now with Eglot, and so on.
So if you want it to be, yes and with a lot of support out of the box these days.
I feel like I still have yet to see any decent answers to this question; Are professional SDE paying for Claude on their own dime, and then logging into their personal account and somehow integrating Claude Code (or other LLMs) into their work repos that way?
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...
Yes I pay for the most expensive Claude sub with my own money and use it at work.
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
Our company set up some kind of Wise debit card thing where we each get our own number, and they told us "try out any AI tool you want."
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.
Emacs mcp with Claude code driving it? Or is this different as that is what it should be: CC just sending elisp to the mcp and nothing else. Imho that is. Emacs is perfect for it.
If Windows has Copilot built in, then it is obvious that the Emacs operating system needs something similar! ;-)
Looks better than my current Claude Sonnet integration via copilot.
Might SWE agents converge on an inclusive set of APIs that Editors and IDEa could adapt to?
i suppose if llm is doing most of the coding going forward, IDEs become less relevant i suppose
What's its monetization?
Emacs developers are the rare breed of sex workers who take it up the rear for pleasure, not money.
Yes, the singularity will happen in emacs.
I don’t really see the point, but it’s certainly interesting
This is the way.
I hope one day we can have the same thing for the helix editor.
See also this other integration of Claude Code for emacs:
https://github.com/cpoile/claudemacs
I want something like this for helix!
claude team unfortunately didn't make it easy for anyone to build their own. Take a look at this if you are hoping to build your own ide integration
https://github.com/coder/claudecode.nvim/blob/main/PROTOCOL....
https://github.com/coder/claudecode.nvim/blob/main/ARCHITECT...
I love(d) Emacs a lot a few years ago. Until my job and obligations didn’t leave me much room for tinkering. There is an inverse relationship between tinkering and getting things done. Although LLMs changed the game: These days I leave the tinkering to Claude Code. And can change every aspect of my tools within seconds. No waste of time, max output. But I still moved away. why? Because I believe the Emacs way is wrong. And here’s why: If I‘d do all my computing in Emacs, I‘d miss out on MailMate as a mail app, on Ghostty as my terminal, on Nvim as an editor, Python as my automation language (instead of Elisp where buffer is the data type used most?) and so much more. I like the Unix way: Do one thing, and do it really good: fzf, ripgrep, yazi, lazygit, absolutely awesome apps for the console. And all can communicate with each other via pipes! So I moved away, and never was happier.
Unfortunate to see more of this horseshit.
[dead]
[dead]
[dead]
[dead]
It's interesting that AI fulfilled for the common user—through vibe coding—the mission which GNU/FSF could not: the freedom to create any software you want at any time. And it's ironic that of all of the software used to create AIs (like PyTorch and NVIDIA's CUDA stack), none of it was licensed GPL, though plenty of it is OSS. GNU is no longer relevant and, compared to MIT and BSD licenses, really never was. RIP FSF.
This is profaning the temple of St iGNUcius