The reason Emacs survived 50 years while countless modern IDEs rose and died is architectural: Emacs isn't just a text editor with a plugin API—it's an interactive Lisp runtime that treats text buffers as first-class citizens.
Modern editors build layers upon layers of IPC, JSON-RPC protocols, and sandboxed extensions to keep the user from touching the core. Emacs did the opposite: it gave the user direct access to the live execution state. You don’t "configure" Emacs from the outside; you mold it into the exact operational extension of your own thought process.
In an era where modern developer tools consume gigabytes of memory just to render a UI tree, there is something deeply grounding about a piece of software from 1976 that still offers the most malleable computing medium on earth.
GNU Emacs really didn't start until 1984, but I keep thinking it would be interesting to compare Emacs' resource usage to Zed (or Gram). Then I realize I can't be bothered to run either of those long enough to do it.
Compared to VSCode, Eight Meg And Constantly Swapping does sound ridiculously parsimonious in 2026.
It's kind of striking how that joke post about ed (from 1991) presented Emacs as extremely resource-wasteful
https://www.gnu.org/fun/jokes/ed-msg.html
but I guess trends elsewhere were so keen on adding abstractions that now Emacs is an efficient, parsimonious choice by comparison.
Some of us would say it is a Lisp programming environment, with influences from Lisp Machines (Zmacs), having a text editor as sample application.