> [W]e are here to declare our intent to use and develop a version of Emacs that is free from LLM-generated contributions regardless of whatever policy GNU decides upon. We invite them to weigh the costs and do the right thing, in which case we will continue to support them. But if they are not willing to do so, we will continue to use and develop an LLM-free version of Emacs anyway, even if it is not GNU Emacs.

https://human-emacs.org/

  > I believe a sufficiently interested emacs developer with a

$100 plan and a long weekend could hammer out a pretty good first cut. That no one's yet done it is clear evidence that no one really wanted these things so much as they wanted to talk about it.

The disappearance of bikeshedding doesn't look like an obvious one but it's a huge loss. Imagine if every scientist resolved to refer to already written books and carry on their research in closed labs with no discussion with the rest of their field.

“AI has turned Stallman's goal of software freedom on its head. Having your computer do whatever your imagination can think up -- that's real freedom. The only catch is you'll have no idea how it works. No one does.”

I more or less agree with the article but we can move it one step further. Nowadays we don't even need text editors no matter how advanced they are. I am a VS Code user and I have not opened VS Code in more than 3 months because I don't need it anymore. Opening a text editor and editing code by hand seems like so ... yesterday.

This definitely is a new era and, personally, I love it! (Also I have broken my right arm so I can't write code even if I wanted to. I'm dictating this text.)

It's a whole new world.

We need to be thinking about modularity with well-defined APIs now, to isolate the chunks created by AI coding. Maintainabilty requires firewalls.

> RMS appeared in a recent video recounting his CSAIL work on a circuit analyzer in which he, and I'm paraphrasing, "didn't model the circuit as a system of equations to be solved, but rather approached it much as a human would" by applying a series of diagnostics.

bitter-lesson-pilled RMS before GTA VI

Loved it.

> But there's one glaring headscratcher, and that's its full-blown, self-contained implementation of a terminal emulator, in Rust no less. In the before times, a developer would undoubtedly seek such a heavy lift from off-the-shelf kit, but the holmes replicated over a coffee break what a billionaire with infinite resources had been toiling over the last five years.

Is this really true, though? Did model improvement since Ghostty began simply eclipse Ghostty and anything achievable with that now "legacy" code base? Would that project be better off abandoned or started over from scratch with Opus 5.5? Or is there something more there?

These are honest questions.

"We may have felt safe bringing a gun to a knife fight, but now everyone's just sending a drone." Perfectly said. For those of us concerned about editor efficiency, it's hard to know where to go from here. For years I'd been working on a design tool that was inspired by Vim - entirely keyboard driven using mnemonic keychords. But LLMs really took the wind out of my sails, because eh, why bother now? Somewhere deep down I feel that it's still viable, because I want it to be true that perfectly deterministic tooling is still important. I just don't know if it will be considered important by everyone else.

> The irony is rich that AI has turned Stallman's goal of software freedom on its head. Having your computer do whatever your imagination can think up -- that's real freedom. The only catch is you'll have no idea how it works. No one does.

Why are people so sure this will keep scaling? We're still so far away from me being able to get anything even remotely close to what I can imagine using a free model running on hardware I own.

Then you need to remember there are a lot of very powerful people currently invested in not letting us have any of this, so I really don't think it's time to call free software irrelevant yet.

> sealed up transistors can reproduce the same outputs given the same inputs with unerring precision. The power to unambiguously differentiate an on- versus an off-signal -- the binary "digital" -- might seem trivial, but is 100% the reason why we're so comfortable handing over the reins to computers.

Is the author not familiar with the ECC memory business?

> Whither now, we ask -- now that we have, even to my jaded eye, a god machine that makes short work of all the stuff we emacsers believed we were faster at than people using lesser tools. Editing speed, customization, the expressiveness of LISP: every advantage we claimed vanished the moment we stopped typing and started telling the AI what we wanted.

Is that a common thought? I learned vim, then emacs, and various other tooling not because I wanted to increase my speed competitively, but just to reduce my frustration with the gap between thinking and doing. Using something like VSCode to code is like playing on a laggy piano (if that exists). You think about I need to quickly update the signature of this function and it turns into a mouse/keyboard chaotic dance with your eyes focusing all over the place. It's like doing a three legged race.

With emacs and vim, I think about the code, notice that I want to change to change something, and can do the necessary actions (almost) subconsciously. Which means, I never stop thinking about the code. It may be longer or faster than someone using another software, but the advantage for me is to rely mostly on muscle memory while I'm thinking deeply about some problems.

Another thing is multiple buffer/views at once. This is why I don't like editors that have vim mode, because it's a pain to browse code with them, especially when you want a global view of something. With both emacs and vim, I can have multiple related files/sections of files/output of commands visible at once. Like how you would want physical papers and lay them on a desk.

Here's a fun question - if AI is trained on OSS, particularly with licenses that are copy left... wouldn't that make all the code it generates copy left? wouldn't that mean the weights themselves should all be open sourced.

>ut at the time, rules-based programming was still novel enough to be considered a viable approach to AI.

Pick MLite from https://t3x.org and you'll get it pretty fast. Or with invariants under Lisp. Or its weird cousing, CLIPS, born from Common Lisp clauses.

On code quality, Neomacs (an Emacs clone in Rust, it has Elisp support) crashes a lot. And by a lot, I mean once you hit the menu with the mouse, it segfaults.

>he only catch is you'll have no idea how it works. No one does.

Is not about the rules, but the relations. It's a network of clauses, and not something akin to if-then-else with flow controlling. There's no actual "flow".

I'm still not using AI to do more than get me in the door with finding new features, like: "tell me how to get my matplotlib output into tiff".

The AI tooling seems too unstable still.

[flagged]

The whole idea of free software seems quaint.

Like demanding commented machine code between 1985 and 2025.

Sure you can get it, but that's not where the software lives even if it's how the software runs.

Reverse engineering closed source software is the simplest thing in the world now. The only reason why more of it isn't done is because it's so boring even minding the AI isn't worth most people's time.

Fable 5.2 is designing entire devices now, from PCB layout to case assembly.

If you're in a STEM program at university, quit. By the time you graduate, you will have negative value proposition compared to Claude. Get into business. The only way you're going to make it is to join the ownership class. Or pick up a torch or pitchfork and join the revolution.