Terrible analogy. Emacs has always had comparably fewer major options for packages compared to other tools, there is often an obvious option based on your needs, and it has never been my experience that people decide to just roll their own versions of everything. The author has clearly never used neovim or now pi. NPM packages in general would have also been a way better example.
Edit: Sure there is some small overlap here, but it's really not comparable and definitely not like the way the author describes things. User personalization in Emacs has normally been on a much smaller scale than rewriting entire packages. Configuration is generally smaller tweaks or things on top of existing packages because Emacs provides cohesive extensibility to the point that it often doesn't require "rolling your own." Most packages are already extremely configurable and tailorable. You don't magically get that sort of environment with LLMs. Emacs is much more cooperative/generalized.
The scale and type of custom/personalized software we're seeing now with AI is completely different from how things have been in Emacs. I'm not saying that's a good or bad thing (I think it's both), but it's very different from Emacs and definitely more comparable to something like vim/neovim where (in part just because of the sheer popularity) you constantly have people "rolling their own" packages and a billion versions of everything. Even that is not a great analogy. This is something completely new.
No one mentioned vi, I like neovim just fine, and I'm using pi daily. Nice try though. My only point is that if you want to talk about rewriting everything yourself, NIH, churn, whatever you want to call it, Emacs is absolutely not a great example.
Are we reading the same article? OP is saying LLMs let normies tweak their personal workflows in the same way we emacs nerds had been doing for decades. Contrary to the old saw about it being an OS, Emacs is really just a shell but with lisp as its command language instead of unwieldy bash. Once Claude magicked an English to bash translator, raw shell has caught up to emacs in its ease of use.
The new thing where everyone just vibe codes their own versions of everything is not at all like personalizing Emacs.
Specifically the idea that people generally just ignore existing versions of packages and make their own has never been the case, especially compared to other editors (even VSCode).
> There are popular elisp packages lots of people use. But except for Magit, nerds are alarmingly apt to replace them with their own shinier versions (and then to show them off, transitioning to the spore-forming phase of the elisp lifecycle). Everything in Emacs is malleable.
> Until now, the Achilles heel of Emacs culture has been that, except for Magit, its packages tend to be wretched user experiences. Ugly, slow, and discoverable only after inflicting years of elisp cortical injuries on yourself.
They are no saints, but at least their solution is actually open source and they can not lock me in like the others can. To illustrate the point, you can replace "Ollama Cloud" with "OpenCode Go" if you want. Or if you prefer you can give enough hardware to run the larger open weight models on my own.
Huh. So what do you think "modality" is? Emacs is inherently a modal editor. Transients, isearch, chords (when it expects another key after C-c or C-x) - that's all modality. VSCode has tons of modal features built-in - multi-cursor/selection state; snippet tab stops, rename symbol, breadcrumb nav - all that modality. Submlime has a genuine first-class modality built into its core.
The idea of vim navigation simply offers some structure and mnemonics - why should I learn hundreds of different ways to deal with text in every app, if there exists an established, well tested, popular way that can simplify it all?
That exactly what it is. People's reaction is a default pattern-matching on "AI executes code on your machine." - Ay the horrors!. They have no idea of my cybersec posture, my network perimeter - vpn, firewall, malware protection, etc.
It's not like I'm giving the LLM root shell. It's as if I said: "I learned how to juggle three chainsaws - so fun...", and people reacted as if I suggested doing that in a school bus full of children going 140kmh down the highway.
It's culturally fitting for HN - signaling caution is always socially safe. Nobody ever got criticized for saying "that sounds risky". But "I evaluated the risks and accepted the tradeoffs for my situation" is the actual, pragmatic engineering. Security is risk management, not risk elimination.
Hyprland works with nvidia just fine with minimal coniguration, just as well as any other wayland compositor I've tried, and I have a very old card. Having out of date packages is going to be an issue on Ubuntu for software in general, but probably sway would be better to try.
There is also scroll (sway fork) and plugins for hyprland. Scrolling experience was not actually better in niri vs. others in my experience just because it was built around it. I tried to use niri, but there is too much missing functionality I want compared to hyprland and also worse power consumption.
Workspaces are not bound to displays in hyprland. This is one major reason I'm using hyprland over niri, where it's not really possible to work around that issue.
Every monitor has its own set of workspaces. Workspace 4 on display A is not the same as Workspace 4 on display B is not the same as Workspace 4 on display C.
Functionally you can focus any workspace on any monitor, and ids do not change when doing that. You can set things up both ways, but it's actually easier to just have a key focus workspace x on the current monitor than to lock workspaces to specific monitor.
Edit: Sure there is some small overlap here, but it's really not comparable and definitely not like the way the author describes things. User personalization in Emacs has normally been on a much smaller scale than rewriting entire packages. Configuration is generally smaller tweaks or things on top of existing packages because Emacs provides cohesive extensibility to the point that it often doesn't require "rolling your own." Most packages are already extremely configurable and tailorable. You don't magically get that sort of environment with LLMs. Emacs is much more cooperative/generalized.
The scale and type of custom/personalized software we're seeing now with AI is completely different from how things have been in Emacs. I'm not saying that's a good or bad thing (I think it's both), but it's very different from Emacs and definitely more comparable to something like vim/neovim where (in part just because of the sheer popularity) you constantly have people "rolling their own" packages and a billion versions of everything. Even that is not a great analogy. This is something completely new.
reply