A big loss for the Emacs community! emacs-aio is great!
I see the author is spring cleaning:
> I've
turned over a new leaf (no more Openbox, Tridactyl, Xorg, xterm), and so
some of these things I no longer use. On Linux I now use KDE on Wayland
with a minimally-configured browser. I miss the power user features, but
I do not miss the friction and constant maintenance.
LLMs have inspired a similar change in me: with a big change in how I work, I feel I can and should be more flexible with adopting new tech, which involving freeing myself of previous choices.
FWIW, the age of LLMs made me build a deeper, more intimate relationship with Emacs, because it's a Lisp REPL loop with a built-in editor, not the other way around. When you give an LLM a closed loop system where it can evaluate code in a live REPL and observe the results, it stops guessing and starts reasoning empirically.
LLM that I run inside Emacs can fully control the active Emacs instance. I can make it change virtually any aspect of it. To load-test things, I even made it play Tetris in Emacs. And not just simply run it, but to actually play it without losing. It was insane.
Also, Emacs is all about plain text - you can easily extract text from anything - from the browser, terminal, CLI apps, Slack, Jira, etc., and you can do that on your own terms - context can appear in a buffer, in your clipboard, become a file or series of API requests. That is really hard to beat.
Asolutely. It doesn't have to be an either-or. I use gptel and org mode when I was to be really hands on driving the development. It's a very different mode of interacting with models, and the way newer models are trained to play nice with harnesses makes them very obedient.
Same here. Emacs has been the stable editor for all kinds of language changes, tool changes, and IDE changes. Emacs is great with LLM, as LLM is mostly text related and Emacs is great in capturing and dealing with text.
Big same. I have been doing a lot of clojure development, and hooking up my app to a live REPL has given me an absolutely fantastic feedback loop for the LLM. I don't think a lot of people understand what they're missing.
I am really loving working on a fun Elisp project with pi, a minimal and very extensible agent. I have the agent use emacsclient to control my session, showing me code, running magit ediff for me, testing, formatting, reloading -- it's all working great.
I'm still exploring all the ways the agent and I can collaborate using Emacs as a shared medium, but at the moment am super optimistic about it.
One example: it disables the default Ctrl-F search function but its own search function is subpar (no match counts/hlsearch, e.g.) and often clashes with website's built-in search (on Github, e.g.).
It doesn't work on the default newtab either, and changing the default newtab somehow makes opening a new tab slower (that's FF's fault, I guess)…
cool to see you in the wild, for me, it does work out of the box however, some sites will break or have too complex of a navigation, especially with iframes. and will have to swap to a mouse which is a bummer, which I understand is an inherent limitation of the tech, since web is not built today to do that.
I am running Ubuntu as my desktop operating system. I would never do this without an LLM to do the work of keeping it functional for me. Today, Rise of Nations wouldn't launch. Never had that problem before. Seems the driver for 32-bit games and my Nvidia GPU weren't getting along after an update. Codex was called in and solved the problem for me in about 5 minutes. I just copied and pasted the Steam log and let it tell me what to do. Tadah.
I'm actually excited about the potential for a future where local agents help improve the operating system experience as I go by making changes based on my use case. All local, of course. I do not want to trust a cloud provider with my use cases/behavior on my computer so they can sell me more ads...
Does anyone else not understand what people mean when they refer to the "friction" supposedly inherent to these power user tools? Almost none of the configs/scripts/etc I use for my heavily-customized and terminal-heavy setup get changed for years at a time.
If you are frequently having to use other computers, a heavily customized setup has much more friction either to setup the machine like you want, or remember how to do things without all the customization (if you can't customize or it isn't worth the time).
When I graduated college I used Dvorak and Emacs on Linux. Six months of having to use shared Windows lab computers extensively beat me down to surrender all of those points - my brain just couldn't handle switching, so I conformed my desktop to match. Then later I switched jobs to a group that was all Unix, but of many varieties most of which only had vi, not Emacs. And so I learned vi. Sometimes minimizing friction means going with the flow.
Arguably NixOS is the most config heavy platform but it solves the pain point of having to reconfigure on different systems. Especially in the LLM era where I can configure Emacs and my OS decoratively.
Our lives are much more than our computing environments. By surrendering a bit of control of our computing environments we free up our brains to devote to other things in life: loved ones, pets, gardening, home maintenance, other hobbies and sports...
Millions of happy Apple users can't be wrong on this.
The previous post alludes to Evil being the long term plan. That seems sensible: it ought to be easier to use an implementation of Vim in Emacs rather than port much of Emacs to independent applications.
Yet the author ended up doing the latter and it's not really made clear why. Why?
I used emacs full-time for many many years. Then I switched to Vim or other editors with Vim modes, also for many years. I have to be honest, I don’t see a particularly clear winner between them. Model editing is a bit unusual in many ways. There are some things that it certainly makes easier, but I personally found that the overall process of editing and writing code in real time for me was more efficient in a single mode emacs.
> I don’t see a particularly clear winner between them
Because deep down they are incomparable categorically. Separate the tools from the foundational ideas and you see the very different value. Vim-model of text navigation is fantastic, practical, brilliant idea. Once you grok it - you can take it anywhere. You can use it in your editor, browser, terminal, WM. Emacs is rooted in another, even more brilliant idea of practical notation for lambda calculus. These ideas have no overlap. But understanding the philosophy of each (ideally both) could open so many different possibilities.
My vim muscle memory has paid off more for me than my emacs muscle memory. Emacs was the better editor, though. Anything that doesn't have Vimscript is an automatic winner IMO.
I use ^a to go to the beginning of a line and ^e to go to the end nearly everywhere. Many Emacs keystrokes are so pervasive that they're not often thought of as Emacs keystrokes.
My usage of emacs is so vim-like that I’ve tried switching a few times. Vim is definitely faster, and overlays and cursor placement is much simpler and more intuitive. But there were still feature gaps and configuration issues that prevented full adoption.
You may get good bang for your buck out of neovim. With only a very minimal set of plugins, it has replaced all other IDEs for me. (They're also making good progress Sherlocking their core plugins, so the future is bright for those of us who dislike plugins for core functionality.)
can you elaborate? Heavy vim user here, have considered using emacs in vim mode to quell a decades long nagging curiosity. Just need a compelling nudge.
I don't know how much this applies to everyone else, but the ability to display images inline is really nice for notetaking. I cannot write properly, so org-mode (a notetaking tool that can export to a variety of formats) with embedded rendered latex equations makes it really easy to take notes and write things up in a plaintext format without needing to export every 30 seconds to view equations. The ability to embed code that can actually run is also very nice.
Emacs is primarily a platform for developing Lisp applications. Lisp applications are immensely hackable, meaning an Emacs configuration can be tailored in detail to specific desires.
There is also an ecosystem of applications for Emacs that are really good. They don't require you to use Emacs as your editor (you can run, say, Magit as a standalone instance) but if you do, they integrate really well with each other.
I've been retired from emacs for several years now but I'm still looking for a magit replacement that is independent of my editor. Vscode's magit extension is really good but i split my time between IntelliJ and vscode.
#!/bin/sh
if [ "$(git rev-parse --is-inside-work-tree)" = "true" ]; then
exec emacs -nw -q --no-splash -l "/path/to/magit-init.el"
fi
It worked well for me because I can reuse all my keybindings (evil + leader keys with `general`) and my workflow is fully in the terminal. (I have since moved on to Jujutsu, and `jjui` is filling this gap for me right now, but it's not quite a magit-for-jj).
Honestly, magit is just a masterclass in UI design. It makes most everything incredibly easy to do while still giving you the ability to tweak things if you need to.
The author is the developer of the RSS reader Elfeed, which a lot of Emacs users use several times a day. Though the article talks about a vibe-coded wxWidgets-based GUI application called Elfeed2 that he wrote as a replacement, Emacs afficionados would be loath to leave their Emacs environment and switch to that. Hopefully Emacs elfeed finds a new maintainer.
I tried Elfeed2 immediately after the announcement, well, it's nowhere near the experience of elfeed in Emacs. Elfeed2 doesn't load content for most of my feeds, elfeed does. I also integrated elfeed-tube, which shows previews of videos and their transcripts, making it no-brainer to get a summary without watching the whole video.
Good. People here it's blind with the CADT model. They aren't even aware than with Elfeed for instance you can automatically set a hook on a feed that it calls lingva.el functions to translate, for instance, feeds written in Spanish or German to your native language in the spot.
Try doing that with Elfeed2.
Vi/Nvi2 users can almost do the same with Unix pipes and apertium/translate-shell/some lingva CLI translating tools for the whole document/regex selection/lines, a la Emacs. So can sfeed users, where depending on the feed they can pipe the plumbers' output (or just hack the scripts) to any other translating tool:
git://codemadness.org/sfeed
Heck, a few years ago I could reuse Telega.el's (Telegram client) translating functions for non-Telega buffers translating some text guide in the spot. So, did the blogger actually win something?
I have long struggled to learn emacs and use it effectively. Just for the fun it, If I were to use claude as I my teacher, how can I ask it to teach me to use Emacs? I don't like to ask questions and go back to try it. I want it to be a drive that will assist me with the usage. Has anyone tried such an approach to learn emacs?
There's a nice built-in tutorial for actually editing text with it. Press control-h then t to launch it. But that's just for using the editor. For actually configuring it, I've found that Opus 4.6 (inside Droid) is exceptionally good at tweaking my init.el.
Yesterday I typed "Set the default YAML indentation to 2 spaces." It came up with
Don't try to "learn Emacs". Grok the foundational layer - Lisp. Emacs is not an editor - it's first and foremost Lisp interpreter with a built-in editor. You need to get two things: REPL (evaluating Lisp expressions in-place) and structural editing (moving, expanding, transposing expressions).
You can start with vanilla Emacs with zero config and Claude/Copilot/Codex/etc, running separately. Your first goal is to have the LLM running inside Emacs - ask the LLM how. It probably will recommend gptel - as one of the most popular and robust choices, go with it.
Once you get LLM tools to modify Emacs state from within, you can just go crazy. You can tell it to change colors, fonts, ask any stupid questions, whatever. It will do it without losing a beat - no restarts, no waiting, no copy pasting - just flow.
My advice is to use a base, vanilla Emacs for a little while to learn where its boundaries go, before installing a bunch of modes. That makes it easier to troubleshoot problems later.
If the author is on, I'm curious why he chose wxWidgets instead of Qt; I'd be surprised if it is that much lighter weight than Qt. (I even wrote my own cross-platform toolkit with "more lightweight" as one of the reasons, and if you use all the features, it weighs in about the same size as Qt, I think.) Also, the last time I used wxWidgets, many years ago, it had a clunky MFC style to it, limited feature, along with a rather Windowsy look and feel. Have those things changed?
My experience with wxWidgets based apps is that they tend to not handle DPI scaling well. Audacity is a good example, IIRC that's one of the reasons they're moving to Qt.
I was wondering how people feel about this trend. LLM allow you to free yourself from foundations (frameworks, programmable programs) to just generate any support layer you want from old or new libs. This is all very understandable.. yet I find it a loss, in the lisp world, having a core model and semantics shared by all the upper layers means ease of reuse (for instance people leverage emacs calc classes in other places), llm allows for easier fragmentation..
I also suspect it allows easier consolidation. Moving from a deprecated lib to a new (and better) one for example.
Implementations will likely homogenize a bit as well, but on the other hand boy am I glad not to see an increasing amount of bizarre naïve hand-rolled implementations for some things.
Why? What makes Spacemacs so different/special that it requires some kind of distinct opinion that would be extremely valuable? Spacemacs is the same old Emacs with some out-of-the box customizations atop - there's nothing fundamentally different about it.
"The" future of software engineering is a silly thing to predict. I might predict one substantial change is that we get our house a little more in order about universities and the private sector distinguishing between computer science, software engineering, and software development. Obviously they are not cleanly separated[1], but LLMs will affect each subfield very differently.
- The impact on computer science seems almost entirely negative so far: mostly the burden of academic wordslop, though an additional negative impact is AI sucking all the air out of the room. What's worse is how little interesting computer science has come out of the biggest technological development with computers in many years: in fact there has been a terrible and very sudden regression of scientific methodology and integrity, people rationalizing unscientific thinking and unprofessional behavior by pointing to economic success. I think it'll take decades to undo the damage, it's ideological.
- The impact on software development actually does seem a bit positive. I am not really a software developer at all. It always felt too frustrating :) However the easing of frustration might be offset by widespread devastation of new FOSS projects. I don't want to put my code online, even though I'm not monetizing it. I'm certainly not alone. That makes me really sad. But I watched ChatGPT copy-paste about 200 lines of F# straight from my own GitHub, without attribution. I'm not letting OpenAI steal my code again.
- Software engineering... it does not seem like any of these systems are actually capable of real software engineering, but we are also being adversely affected by an epidemic of unscientific thinking. Speaking of: I would like to see Mythos autonomously attempt a task as complex and serious as a C compiler. Opus 4.6 totally failed (even if popular coverage didn't portray it as such):
The resulting compiler has nearly reached the limits of Opus’s abilities. I tried (hard!) to fix several of the above limitations but wasn’t fully successful. New features and bugfixes frequently broke existing functionality.
"Future of software engineering" folks should stuff like this in mind. What model is going to undo Mythos's mess? What if that mess is your company's product? Hope you know some very patient humans!
[1] They should have different educational tracks. There is no reason why a big fancy school like MIT can't have computer scientists do something like SICP and software engineers do the applied Python class. Forcing every computer professional into "computer science" is just silly; half the students gripe about how useless this theory is, the other half gripe about how grubby the practice is. What really sucks here is that I think Big Tech would support the idea, we're just stuck in a weird social rut.
To toss them because the level of damage they have done it's astounding. Tons of companies are still fixing the losses from vibe coding.
What we need it's better code analizers, lexers and the like. And LLM's are practically the opposite because they can't never, ever give a concise answer by design. Worse, they rot over time.
> With my newly-acquired superpowers I could knock out the last two pieces in a few days’ work
From the linked post:[0]
> I left an employer that is years behind adopting AI to one actively supporting and encouraging it. As of March, in my professional capacity I no longer write code myself. My current situation was unimaginable to me only a year ago. Like it or not, this is the future of software engineering. Turns out I like it, and having tasted the future I don’t want to go back to the old ways.
It's deeply distressing to watch people fall into AI psychosis. Being smart, accomplished, or experienced is no defence.
After the bubble pops and the industry realises the damage these tools can do to people, folks like the author will have to confront that they were taken in by a lie. Many won't be able to confront that.
It's not AI psychosis, you're interpreting what he said to the extreme.
Anyone who has actual corporate team lead or management experience understand AI as effectively a junior dev who doesn't have great persistent memory. These devs using AI are reviewing, guiding, and validating the work given to them by AI just as they would from a junior dev.
The inverse of your statement is more apt; it's distressing to see people so angsty about AI usage. There are going to be skilless vibecoders and then there are going to be experienced devs (like OP) who figured out their AI workflow to multiply their productivity 2-5x.
What the future holds for AI model pricing-- that is a valid concern. But I don't think that's what you intended.
> There are going to be skilless vibecoders and then there are going to be experienced devs (like OP) who figured out their AI workflow to multiply their productivity 2-5x.
Are you sure OP belongs in the second group? He explicitly said he doesn't read all the code generated by his AI:
> I have not read most of the code, and instead focused on results, so you might say this was “vibe-coded.”
this is just like being promoted from developer to manager. some people like it some don't. with AI there is another dimenstion: some people like managing machines instead of people, some don't.
it's not for me. i don't want to stop writing code. i don't mind to manage people but i don't want to manage machines (at least not with an unprecise interface/outcome as AI provides). consequently AI may be fine for this person, but it is not for me.
Now I may be old, but whenever we put a lot of faith in unaccountable megacorps it sure seems to have backfired a lot (remember when Amazon removed 1984 from people's libraries?). As long as a model running locally on a regular laptop bought from the supermarket isn't good enough I'm gonna remain sceptical about current AI.
There's also ethical and environmental considerations, but let's see if we can walk before we try to run.
> It's deeply distressing to watch people fall into AI psychosis.
It's unclear what you're saying here... Yes, AI-induced psychosis is a real problem and the frontier labs' mitigations are ineffective, to put it mildly. But using AI as a coding tool doesn't have anything to do with psychosis.
AI psychosis is to have a toxic relationship with a chatbot as if though it was a real person. It has nothing to do with engineering. You're muddying your own point by conflating all LLM use with some kind of delusion. There is a lot of nuance in this space and you're not doing yourself any favors by ignoring it if you're an engineer. There is no bubble pop, other than a straight up apocalypse, that is going to put this genie back in the bottle. Models are trained. Tools are built. There isn't a single industry that cares about artistry more than efficiency. It's here to stay, it's getting better, and if you don't know how to use it, you're going to have trouble finding work.
> Being smart, accomplished, or experienced is no defence.
Perhaps you're confusing "not using AI" with "not being dependent on AI", those are very different things.
The edge isn't from avoidance, it's from using AI as leverage on top of real skill. A strong developer + AI beats a strong developer alone, and massively beats a weak developer + AI. The edge doesn't come from avoiding a tool - it comes from being the kind of person who doesn't need it but uses it anyway. That's leverage. Refusing to use it is just leaving leverage on the table to make a philosophical point.
> After the bubble pops
People like Chris (who is enormously capable engineer) would just move onto different tools, different techniques and paradigms. That is the essence of being a software developer - many of us choose this path specifically because it forces you to learn something new, every single day. That is (I suspect) also another reason why Wellons decided to migrate away from Emacs - he just learned it so deeply, perhaps it's no longer giving him the satisfaction of learning. Which to be honest is hard to believe - Emacs is a boundless playground, there's always something new to learn there.
I just wonder how jobs like that won't replace their employees. Seems too good to last. In a few years OpenAI will just sell $1,000 per month Human-free Agent Coding for businesses.
Saying they have psychosis is a rude exaggeration.
Not writing code isn't the same as vibe-coding. You can stay on top of AI, make it rewrite the things that look bad, make it refactor until you're happy with how things look, etc....
Maybe a lot of people who are doing that aren't admitting that they've stopped writing code, but when all you're ever doing is manually fixing a few lines, or moving blocks of code to more sensible places, fixing jumbled parameters in a call and such, you're not really writing code anymore. You're now a chef in a kitchen yelling at assistants and just touching things when dealing with communicating a correction to one of those dimwits is more frustrating than just doing it yourself.
You still have to be a cook to be a chef, though. But the reason I say that AI is dumb is because I tell it to do things, it does them in a dumb way, and I complain at it and tell it to write it in a sensible way. It screws that up, and I tell it to do it again, and not to screw it up. I'm still not coding. If it goes into a loop of nonsense, I touch things with the intention of doing just enough to knock it out of that loop (or rather keep the new context from falling into it.)
"After the bubble pops" we might see that a lot of new chefs can't actually afford assistants. But just as likely, the overbuilt (government-subsidized directly and through policy) capacity might end up getting written off, and at the cost of electricity and maintenance costs could stay reasonably good. Or algos improve. Or training methods improve.
AI is dumb is because I tell it to do things, it does them in a dumb way, and I complain at it and tell it to write it in a sensible way. It screws that up, and I tell it to do it again, and not to screw it up. I'm still not coding. If it goes into a loop of nonsense, I touch things with the intention of doing just enough to knock it out of that loop (or rather keep the new context from falling into it.)
it is inconceivable to me how anyone could ever enjoy working like that. but whatever floats their boat.
No. AI is a must for software development. It's non-negotiable. The productivity gains are too great. The era of 100% human-written code is over. People will still do it as an idle curiosity, for personal projects only they intend to use. But even those open source projects with significant user bases that forbid the use of AI (like, afaik, NetBSD) will be eclipsed by those that support it in terms of features, capability, and security. And the commercial world? Forget it. You cannot keep pace with your employer's expectations unless you learn to use these tools well. This is not up for debate. It's reality.
Plenty of accomplished devs are getting good results and accomplishing tasks with unheard-of speed using AI, so if you're still not, that's a PEBKAC. You are not using the tools correctly. Figure it out before you complain.
> "No. AI is a must for software development. It's non-negotiable."
Absolutist rubbish.
> "But even those open source projects with significant user bases that forbid the use of AI [...] will be eclipsed by those that support it in terms of features, capability, and security."
As is this. If a language model is relevant to a project, open source or otherwise, is of course heavily dependent on its nature (ethics, use case, deployment, working environment/culture, et cetera).
LLMs may be a must for programming, but not for engineering. Writing code is the easy part once you figure out what actually needs to be built in the first place.
I know this is the joke, and I know Evil is the jokey reply, but ... both sides of the joke carry a grain of truth, as good jokes do.
I know a lot of people become comfortable with the default editing tools in Emacs, and many of them are good, but on the whole, vanilla Emacs does not ship with a great editor.
The Vim family makes up amazingly well designed editors.
Evil is a Vim implementation in Emacs. It is the best of both worlds, and not just on paper. It actually works.
A big loss for the Emacs community! emacs-aio is great!
I see the author is spring cleaning:
> I've turned over a new leaf (no more Openbox, Tridactyl, Xorg, xterm), and so some of these things I no longer use. On Linux I now use KDE on Wayland with a minimally-configured browser. I miss the power user features, but I do not miss the friction and constant maintenance.
https://github.com/skeeto/dotfiles/commit/df275005769b654618...
> I am no longer using Mutt nor running my own mail server. In general less terminal stuff for me.
https://github.com/skeeto/dotfiles/commit/e331e367c75f66aaa9...
LLMs have inspired a similar change in me: with a big change in how I work, I feel I can and should be more flexible with adopting new tech, which involving freeing myself of previous choices.
> LLMs have inspired a similar change in me
FWIW, the age of LLMs made me build a deeper, more intimate relationship with Emacs, because it's a Lisp REPL loop with a built-in editor, not the other way around. When you give an LLM a closed loop system where it can evaluate code in a live REPL and observe the results, it stops guessing and starts reasoning empirically.
LLM that I run inside Emacs can fully control the active Emacs instance. I can make it change virtually any aspect of it. To load-test things, I even made it play Tetris in Emacs. And not just simply run it, but to actually play it without losing. It was insane.
Also, Emacs is all about plain text - you can easily extract text from anything - from the browser, terminal, CLI apps, Slack, Jira, etc., and you can do that on your own terms - context can appear in a buffer, in your clipboard, become a file or series of API requests. That is really hard to beat.
Asolutely. It doesn't have to be an either-or. I use gptel and org mode when I was to be really hands on driving the development. It's a very different mode of interacting with models, and the way newer models are trained to play nice with harnesses makes them very obedient.
https://poyo.co/note/20260202T150723/
2 replies →
Same for me!
My .emacs config has improved and I wrote my own Emacs based coding agent https://github.com/mark-watson/coding-agent
Same here. Emacs has been the stable editor for all kinds of language changes, tool changes, and IDE changes. Emacs is great with LLM, as LLM is mostly text related and Emacs is great in capturing and dealing with text.
So much this. Lisp can do things other languages have a hard time with. I think a resurgence is in order.
3 replies →
Can you describe your setup on how you use LLMs within Emacs?
1 reply →
Big same. I have been doing a lot of clojure development, and hooking up my app to a live REPL has given me an absolutely fantastic feedback loop for the LLM. I don't think a lot of people understand what they're missing.
1 reply →
I am really loving working on a fun Elisp project with pi, a minimal and very extensible agent. I have the agent use emacsclient to control my session, showing me code, running magit ediff for me, testing, formatting, reloading -- it's all working great.
I'm still exploring all the ways the agent and I can collaborate using Emacs as a shared medium, but at the moment am super optimistic about it.
> LLM that I run inside Emacs can fully control the active Emacs instance ... > you can easily extract text from anything
This is what gives me the most pause.
13 replies →
I wonder what friction/maintenance he found with Tridactyl
For me the friction always comes when I try to use the internet without it
We're talking about https://addons.mozilla.org/en-US/firefox/addon/tridactyl-vim...?
One example: it disables the default Ctrl-F search function but its own search function is subpar (no match counts/hlsearch, e.g.) and often clashes with website's built-in search (on Github, e.g.).
It doesn't work on the default newtab either, and changing the default newtab somehow makes opening a new tab slower (that's FF's fault, I guess)…
1 reply →
cool to see you in the wild, for me, it does work out of the box however, some sites will break or have too complex of a navigation, especially with iframes. and will have to swap to a mouse which is a bummer, which I understand is an inherent limitation of the tech, since web is not built today to do that.
solid extension, big fan
I'm not the author, but I recently gave up on Firefox, sadly.
Since I needed to keep around a Chromium anyway, and I already am forced to use one for work, it became simpler to just use solely use a Chromium.
In the process I dropped some extensions.
It's been great.
2 replies →
I am running Ubuntu as my desktop operating system. I would never do this without an LLM to do the work of keeping it functional for me. Today, Rise of Nations wouldn't launch. Never had that problem before. Seems the driver for 32-bit games and my Nvidia GPU weren't getting along after an update. Codex was called in and solved the problem for me in about 5 minutes. I just copied and pasted the Steam log and let it tell me what to do. Tadah.
I'm actually excited about the potential for a future where local agents help improve the operating system experience as I go by making changes based on my use case. All local, of course. I do not want to trust a cloud provider with my use cases/behavior on my computer so they can sell me more ads...
LLM discourse inspires me to do a cleaning of my browser tabs every hour.
Does anyone else not understand what people mean when they refer to the "friction" supposedly inherent to these power user tools? Almost none of the configs/scripts/etc I use for my heavily-customized and terminal-heavy setup get changed for years at a time.
If you are frequently having to use other computers, a heavily customized setup has much more friction either to setup the machine like you want, or remember how to do things without all the customization (if you can't customize or it isn't worth the time).
When I graduated college I used Dvorak and Emacs on Linux. Six months of having to use shared Windows lab computers extensively beat me down to surrender all of those points - my brain just couldn't handle switching, so I conformed my desktop to match. Then later I switched jobs to a group that was all Unix, but of many varieties most of which only had vi, not Emacs. And so I learned vi. Sometimes minimizing friction means going with the flow.
A heavily-customised setup is very comfortable.
It's so comfortable that it acts as an impediment to change, since some types of change are uncomfortable.
This can feel like friction to me.
When I remove customisation, I am more "open to experience", and often find preferable tooling.
Arguably NixOS is the most config heavy platform but it solves the pain point of having to reconfigure on different systems. Especially in the LLM era where I can configure Emacs and my OS decoratively.
1 reply →
> heavily-customized and terminal-heavy setup
this exactly. most people can’t set it up that well.
[flagged]
"more flexible with adopting new tech" and "freeing myself of previous choices" are completely unrelated to what you just wrote.
Especially ridiculous because old-school bash CLI scripts is the only usable protocol for interacting with LLM agents.
How on earth did you get that from the segment of text that you chose to quote?
Our lives are much more than our computing environments. By surrendering a bit of control of our computing environments we free up our brains to devote to other things in life: loved ones, pets, gardening, home maintenance, other hobbies and sports...
Millions of happy Apple users can't be wrong on this.
4 replies →
The previous post alludes to Evil being the long term plan. That seems sensible: it ought to be easier to use an implementation of Vim in Emacs rather than port much of Emacs to independent applications.
Yet the author ended up doing the latter and it's not really made clear why. Why?
I used emacs full-time for many many years. Then I switched to Vim or other editors with Vim modes, also for many years. I have to be honest, I don’t see a particularly clear winner between them. Model editing is a bit unusual in many ways. There are some things that it certainly makes easier, but I personally found that the overall process of editing and writing code in real time for me was more efficient in a single mode emacs.
> I don’t see a particularly clear winner between them
Because deep down they are incomparable categorically. Separate the tools from the foundational ideas and you see the very different value. Vim-model of text navigation is fantastic, practical, brilliant idea. Once you grok it - you can take it anywhere. You can use it in your editor, browser, terminal, WM. Emacs is rooted in another, even more brilliant idea of practical notation for lambda calculus. These ideas have no overlap. But understanding the philosophy of each (ideally both) could open so many different possibilities.
You can take modal editing anywhere, but that doesn't mean you should.
Why not both? Evil is a reimplementation of Vim in Emacs and it is great.
1 reply →
My vim muscle memory has paid off more for me than my emacs muscle memory. Emacs was the better editor, though. Anything that doesn't have Vimscript is an automatic winner IMO.
I use ^a to go to the beginning of a line and ^e to go to the end nearly everywhere. Many Emacs keystrokes are so pervasive that they're not often thought of as Emacs keystrokes.
2 replies →
Evil is a tried-and-true Vim implementation that doesn't use Vimscript!
My usage of emacs is so vim-like that I’ve tried switching a few times. Vim is definitely faster, and overlays and cursor placement is much simpler and more intuitive. But there were still feature gaps and configuration issues that prevented full adoption.
You may get good bang for your buck out of neovim. With only a very minimal set of plugins, it has replaced all other IDEs for me. (They're also making good progress Sherlocking their core plugins, so the future is bright for those of us who dislike plugins for core functionality.)
can you elaborate? Heavy vim user here, have considered using emacs in vim mode to quell a decades long nagging curiosity. Just need a compelling nudge.
If you haven't used it before, give it a shot. Worst case you waste a few years of your life.
Doom emacs and Spacemacs are both good starter kits to give you an idea of what you could do.
I don't know how much this applies to everyone else, but the ability to display images inline is really nice for notetaking. I cannot write properly, so org-mode (a notetaking tool that can export to a variety of formats) with embedded rendered latex equations makes it really easy to take notes and write things up in a plaintext format without needing to export every 30 seconds to view equations. The ability to embed code that can actually run is also very nice.
Check out Doom Emacs if you are looking for a good starting point. The defaults make sense coming from Vim.
Emacs is primarily a platform for developing Lisp applications. Lisp applications are immensely hackable, meaning an Emacs configuration can be tailored in detail to specific desires.
There is also an ecosystem of applications for Emacs that are really good. They don't require you to use Emacs as your editor (you can run, say, Magit as a standalone instance) but if you do, they integrate really well with each other.
+1
I've been retired from emacs for several years now but I'm still looking for a magit replacement that is independent of my editor. Vscode's magit extension is really good but i split my time between IntelliJ and vscode.
Anyone know of something like this?
When I still used Git, I used to have a minimized `magit-init.el` that essentially did:
And a small wrapper (`~/.local/bin/magit`):
It worked well for me because I can reuse all my keybindings (evil + leader keys with `general`) and my workflow is fully in the terminal. (I have since moved on to Jujutsu, and `jjui` is filling this gap for me right now, but it's not quite a magit-for-jj).
Lazygit is the closest thing I've seen; it's what I use on remote hosts when TRAMP-ing into Magit would be too painful.
lazygit is too slow for me.
If you are on Linux/Gnome, try out Stage:
https://flathub.org/en/apps/io.github.aganzha.Stage
I was a loyal magit user for a decade. Now I use jujutsu from the command line. It's actually really nice.
>i split my time between IntelliJ and vscode
The IntelliJ git client is my favorite by far, I am curious what do you not like about it?
It's not that i don't like it. It's that I've got 10-15 years (i think) of muscle memory with magit
Honestly, magit is just a masterclass in UI design. It makes most everything incredibly easy to do while still giving you the ability to tweak things if you need to.
https://github.com/altsem/gitu
The author is the developer of the RSS reader Elfeed, which a lot of Emacs users use several times a day. Though the article talks about a vibe-coded wxWidgets-based GUI application called Elfeed2 that he wrote as a replacement, Emacs afficionados would be loath to leave their Emacs environment and switch to that. Hopefully Emacs elfeed finds a new maintainer.
I tried Elfeed2 immediately after the announcement, well, it's nowhere near the experience of elfeed in Emacs. Elfeed2 doesn't load content for most of my feeds, elfeed does. I also integrated elfeed-tube, which shows previews of videos and their transcripts, making it no-brainer to get a summary without watching the whole video.
I don't use elfeed, but installed elfeed-tube just for youtube-with-transcripts :)
> I tried Elfeed2 immediately after the announcement, well, it's nowhere near the experience of elfeed in Emacs.
Isn't that kinda expected with a new software release, that it doesn't have a 100% feature parity?
3 replies →
Yeah, I'm not gonna use anything vibe-coded, all those apps are total trash.
Good. People here it's blind with the CADT model. They aren't even aware than with Elfeed for instance you can automatically set a hook on a feed that it calls lingva.el functions to translate, for instance, feeds written in Spanish or German to your native language in the spot.
Try doing that with Elfeed2.
Vi/Nvi2 users can almost do the same with Unix pipes and apertium/translate-shell/some lingva CLI translating tools for the whole document/regex selection/lines, a la Emacs. So can sfeed users, where depending on the feed they can pipe the plumbers' output (or just hack the scripts) to any other translating tool:
git://codemadness.org/sfeed
Heck, a few years ago I could reuse Telega.el's (Telegram client) translating functions for non-Telega buffers translating some text guide in the spot. So, did the blogger actually win something?
On the topic of Emacs.
I have long struggled to learn emacs and use it effectively. Just for the fun it, If I were to use claude as I my teacher, how can I ask it to teach me to use Emacs? I don't like to ask questions and go back to try it. I want it to be a drive that will assist me with the usage. Has anyone tried such an approach to learn emacs?
There's a nice built-in tutorial for actually editing text with it. Press control-h then t to launch it. But that's just for using the editor. For actually configuring it, I've found that Opus 4.6 (inside Droid) is exceptionally good at tweaking my init.el.
Yesterday I typed "Set the default YAML indentation to 2 spaces." It came up with
Now I can hit tab to indent YAML by 2 spaces, and I learned a little in the process. I'm delighted with this setup.
> I've found that Opus 4.6 (inside Droid)
What does (inside Droid) mean ? Do you use any package to integrate to claude code in emacs?
1 reply →
Don't try to "learn Emacs". Grok the foundational layer - Lisp. Emacs is not an editor - it's first and foremost Lisp interpreter with a built-in editor. You need to get two things: REPL (evaluating Lisp expressions in-place) and structural editing (moving, expanding, transposing expressions).
You can start with vanilla Emacs with zero config and Claude/Copilot/Codex/etc, running separately. Your first goal is to have the LLM running inside Emacs - ask the LLM how. It probably will recommend gptel - as one of the most popular and robust choices, go with it.
Once you get LLM tools to modify Emacs state from within, you can just go crazy. You can tell it to change colors, fonts, ask any stupid questions, whatever. It will do it without losing a beat - no restarts, no waiting, no copy pasting - just flow.
My advice is to use a base, vanilla Emacs for a little while to learn where its boundaries go, before installing a bunch of modes. That makes it easier to troubleshoot problems later.
If the author is on, I'm curious why he chose wxWidgets instead of Qt; I'd be surprised if it is that much lighter weight than Qt. (I even wrote my own cross-platform toolkit with "more lightweight" as one of the reasons, and if you use all the features, it weighs in about the same size as Qt, I think.) Also, the last time I used wxWidgets, many years ago, it had a clunky MFC style to it, limited feature, along with a rather Windowsy look and feel. Have those things changed?
My experience with wxWidgets based apps is that they tend to not handle DPI scaling well. Audacity is a good example, IIRC that's one of the reasons they're moving to Qt.
I was wondering how people feel about this trend. LLM allow you to free yourself from foundations (frameworks, programmable programs) to just generate any support layer you want from old or new libs. This is all very understandable.. yet I find it a loss, in the lisp world, having a core model and semantics shared by all the upper layers means ease of reuse (for instance people leverage emacs calc classes in other places), llm allows for easier fragmentation..
> llm allows for easier fragmentation..
I also suspect it allows easier consolidation. Moving from a deprecated lib to a new (and better) one for example.
Implementations will likely homogenize a bit as well, but on the other hand boy am I glad not to see an increasing amount of bizarre naïve hand-rolled implementations for some things.
meanwhile I've just started learning it after being in the GUI for decades
Dude only made it 20 years with Emacs. Weak.
I've been using it since 1994.
Whoa, shit, I'm old.
Dang, your emacs config is older than me.
Lugaru (??) emacs (epsilon) on CP/M in the early 1980’s
https://lugaru.com/ They are still around. Most recent epsilon update was last month (but no real release since 2020?).
It was my first experience with emacs as well, but in MS-DOS, ca 1990. Did not know there was a CP/M version.
Would have liked to see author's opinion on Spacemacs, if possible.
Why? What makes Spacemacs so different/special that it requires some kind of distinct opinion that would be extremely valuable? Spacemacs is the same old Emacs with some out-of-the box customizations atop - there's nothing fundamentally different about it.
Searched by tags and found author may try Evil [1], but unsure if they followed through.
You're right Spacemacs is essentially a batteries-included version of Emacs.
[1] https://nullprogram.com/blog/2017/04/01/
1 reply →
But ... why?
> Like it or not, this is the future of software engineering.
For you, perhaps.
What is the future of software engineering in the age of LLMs?
"The" future of software engineering is a silly thing to predict. I might predict one substantial change is that we get our house a little more in order about universities and the private sector distinguishing between computer science, software engineering, and software development. Obviously they are not cleanly separated[1], but LLMs will affect each subfield very differently.
- The impact on computer science seems almost entirely negative so far: mostly the burden of academic wordslop, though an additional negative impact is AI sucking all the air out of the room. What's worse is how little interesting computer science has come out of the biggest technological development with computers in many years: in fact there has been a terrible and very sudden regression of scientific methodology and integrity, people rationalizing unscientific thinking and unprofessional behavior by pointing to economic success. I think it'll take decades to undo the damage, it's ideological.
- The impact on software development actually does seem a bit positive. I am not really a software developer at all. It always felt too frustrating :) However the easing of frustration might be offset by widespread devastation of new FOSS projects. I don't want to put my code online, even though I'm not monetizing it. I'm certainly not alone. That makes me really sad. But I watched ChatGPT copy-paste about 200 lines of F# straight from my own GitHub, without attribution. I'm not letting OpenAI steal my code again.
- Software engineering... it does not seem like any of these systems are actually capable of real software engineering, but we are also being adversely affected by an epidemic of unscientific thinking. Speaking of: I would like to see Mythos autonomously attempt a task as complex and serious as a C compiler. Opus 4.6 totally failed (even if popular coverage didn't portray it as such):
"Future of software engineering" folks should stuff like this in mind. What model is going to undo Mythos's mess? What if that mess is your company's product? Hope you know some very patient humans!
[1] They should have different educational tracks. There is no reason why a big fancy school like MIT can't have computer scientists do something like SICP and software engineers do the applied Python class. Forcing every computer professional into "computer science" is just silly; half the students gripe about how useless this theory is, the other half gripe about how grubby the practice is. What really sucks here is that I think Big Tech would support the idea, we're just stuck in a weird social rut.
2 replies →
To toss them because the level of damage they have done it's astounding. Tons of companies are still fixing the losses from vibe coding.
What we need it's better code analizers, lexers and the like. And LLM's are practically the opposite because they can't never, ever give a concise answer by design. Worse, they rot over time.
https://smsk.dev/2026/04/26/ai-cannot-self-improve-and-math-...
7 replies →
[dead]
[flagged]
> With my newly-acquired superpowers I could knock out the last two pieces in a few days’ work
From the linked post:[0]
> I left an employer that is years behind adopting AI to one actively supporting and encouraging it. As of March, in my professional capacity I no longer write code myself. My current situation was unimaginable to me only a year ago. Like it or not, this is the future of software engineering. Turns out I like it, and having tasted the future I don’t want to go back to the old ways.
It's deeply distressing to watch people fall into AI psychosis. Being smart, accomplished, or experienced is no defence.
After the bubble pops and the industry realises the damage these tools can do to people, folks like the author will have to confront that they were taken in by a lie. Many won't be able to confront that.
[0]: https://nullprogram.com/blog/2026/03/29/
It's not AI psychosis, you're interpreting what he said to the extreme.
Anyone who has actual corporate team lead or management experience understand AI as effectively a junior dev who doesn't have great persistent memory. These devs using AI are reviewing, guiding, and validating the work given to them by AI just as they would from a junior dev.
The inverse of your statement is more apt; it's distressing to see people so angsty about AI usage. There are going to be skilless vibecoders and then there are going to be experienced devs (like OP) who figured out their AI workflow to multiply their productivity 2-5x.
What the future holds for AI model pricing-- that is a valid concern. But I don't think that's what you intended.
> There are going to be skilless vibecoders and then there are going to be experienced devs (like OP) who figured out their AI workflow to multiply their productivity 2-5x.
Are you sure OP belongs in the second group? He explicitly said he doesn't read all the code generated by his AI:
> I have not read most of the code, and instead focused on results, so you might say this was “vibe-coded.”
I no longer write code myself
this is just like being promoted from developer to manager. some people like it some don't. with AI there is another dimenstion: some people like managing machines instead of people, some don't.
it's not for me. i don't want to stop writing code. i don't mind to manage people but i don't want to manage machines (at least not with an unprecise interface/outcome as AI provides). consequently AI may be fine for this person, but it is not for me.
Also from that post:
> Models you can run yourself are toys.
Now I may be old, but whenever we put a lot of faith in unaccountable megacorps it sure seems to have backfired a lot (remember when Amazon removed 1984 from people's libraries?). As long as a model running locally on a regular laptop bought from the supermarket isn't good enough I'm gonna remain sceptical about current AI.
There's also ethical and environmental considerations, but let's see if we can walk before we try to run.
> It's deeply distressing to watch people fall into AI psychosis.
It's unclear what you're saying here... Yes, AI-induced psychosis is a real problem and the frontier labs' mitigations are ineffective, to put it mildly. But using AI as a coding tool doesn't have anything to do with psychosis.
AI psychosis is to have a toxic relationship with a chatbot as if though it was a real person. It has nothing to do with engineering. You're muddying your own point by conflating all LLM use with some kind of delusion. There is a lot of nuance in this space and you're not doing yourself any favors by ignoring it if you're an engineer. There is no bubble pop, other than a straight up apocalypse, that is going to put this genie back in the bottle. Models are trained. Tools are built. There isn't a single industry that cares about artistry more than efficiency. It's here to stay, it's getting better, and if you don't know how to use it, you're going to have trouble finding work.
> Being smart, accomplished, or experienced is no defence.
Perhaps you're confusing "not using AI" with "not being dependent on AI", those are very different things.
The edge isn't from avoidance, it's from using AI as leverage on top of real skill. A strong developer + AI beats a strong developer alone, and massively beats a weak developer + AI. The edge doesn't come from avoiding a tool - it comes from being the kind of person who doesn't need it but uses it anyway. That's leverage. Refusing to use it is just leaving leverage on the table to make a philosophical point.
> After the bubble pops
People like Chris (who is enormously capable engineer) would just move onto different tools, different techniques and paradigms. That is the essence of being a software developer - many of us choose this path specifically because it forces you to learn something new, every single day. That is (I suspect) also another reason why Wellons decided to migrate away from Emacs - he just learned it so deeply, perhaps it's no longer giving him the satisfaction of learning. Which to be honest is hard to believe - Emacs is a boundless playground, there's always something new to learn there.
I just wonder how jobs like that won't replace their employees. Seems too good to last. In a few years OpenAI will just sell $1,000 per month Human-free Agent Coding for businesses.
Saying they have psychosis is a rude exaggeration.
A line? Enjoy the papers telling you otherwise. Not just the cognition it's down, LLM's degrade themselves on every iteration.
Not writing code isn't the same as vibe-coding. You can stay on top of AI, make it rewrite the things that look bad, make it refactor until you're happy with how things look, etc....
Maybe a lot of people who are doing that aren't admitting that they've stopped writing code, but when all you're ever doing is manually fixing a few lines, or moving blocks of code to more sensible places, fixing jumbled parameters in a call and such, you're not really writing code anymore. You're now a chef in a kitchen yelling at assistants and just touching things when dealing with communicating a correction to one of those dimwits is more frustrating than just doing it yourself.
You still have to be a cook to be a chef, though. But the reason I say that AI is dumb is because I tell it to do things, it does them in a dumb way, and I complain at it and tell it to write it in a sensible way. It screws that up, and I tell it to do it again, and not to screw it up. I'm still not coding. If it goes into a loop of nonsense, I touch things with the intention of doing just enough to knock it out of that loop (or rather keep the new context from falling into it.)
"After the bubble pops" we might see that a lot of new chefs can't actually afford assistants. But just as likely, the overbuilt (government-subsidized directly and through policy) capacity might end up getting written off, and at the cost of electricity and maintenance costs could stay reasonably good. Or algos improve. Or training methods improve.
AI is dumb is because I tell it to do things, it does them in a dumb way, and I complain at it and tell it to write it in a sensible way. It screws that up, and I tell it to do it again, and not to screw it up. I'm still not coding. If it goes into a loop of nonsense, I touch things with the intention of doing just enough to knock it out of that loop (or rather keep the new context from falling into it.)
it is inconceivable to me how anyone could ever enjoy working like that. but whatever floats their boat.
No. AI is a must for software development. It's non-negotiable. The productivity gains are too great. The era of 100% human-written code is over. People will still do it as an idle curiosity, for personal projects only they intend to use. But even those open source projects with significant user bases that forbid the use of AI (like, afaik, NetBSD) will be eclipsed by those that support it in terms of features, capability, and security. And the commercial world? Forget it. You cannot keep pace with your employer's expectations unless you learn to use these tools well. This is not up for debate. It's reality.
Plenty of accomplished devs are getting good results and accomplishing tasks with unheard-of speed using AI, so if you're still not, that's a PEBKAC. You are not using the tools correctly. Figure it out before you complain.
> "No. AI is a must for software development. It's non-negotiable."
Absolutist rubbish.
> "But even those open source projects with significant user bases that forbid the use of AI [...] will be eclipsed by those that support it in terms of features, capability, and security."
As is this. If a language model is relevant to a project, open source or otherwise, is of course heavily dependent on its nature (ethics, use case, deployment, working environment/culture, et cetera).
> You cannot keep pace with your employer's expectations unless you learn to use these tools well. This is not up for debate. It's reality.
So the issue isn’t LLM productivity but unrealistic expectations that skyrocketed in the last years? Makes sense.
> Plenty of accomplished devs are getting good results and accomplishing tasks with unheard-of speed using AI
I don’t see any major business impact.
LLMs may be a must for programming, but not for engineering. Writing code is the easy part once you figure out what actually needs to be built in the first place.
1 reply →
> No. AI is a must for software development. It's non-negotiable.
???
https://smsk.dev/2026/04/26/ai-cannot-self-improve-and-math-...
>You are not using the tools correctly.
Stop being deluded, man.
When this crap collapses into itself you will be in tears back asking for the knowledge you failed to get without the fancy Clippys.
Now, stop that fancy Megahal chatbot and learn to do things by hand.
12 replies →
Emacs is an outstanding, extremely powerful piece of software. It just lacks a decent editor.
I know this is the joke, and I know Evil is the jokey reply, but ... both sides of the joke carry a grain of truth, as good jokes do.
I know a lot of people become comfortable with the default editing tools in Emacs, and many of them are good, but on the whole, vanilla Emacs does not ship with a great editor.
The Vim family makes up amazingly well designed editors.
Evil is a Vim implementation in Emacs. It is the best of both worlds, and not just on paper. It actually works.
evil-mode
There’s a lot in a name.
1 reply →
Yuck!