Sometime around 1980-81 I had a part time job while an undergraduate in college doing system programming/admin for the Caltech High Energy Physics department.
Rob Pike was the system programmer/admin before me when he was a grad student in high energy physics, but he left to go work at Bell Labs.
One day another student, Karl Heuer, and I both were engaging in the common programmer pastime of complaining about the screen editors of the day and saying we could write something better.
Somehow this turned into a competition, and we both spent all night racing against each other writing our editors. It was mostly silent except for the typing, interrupted by the occasional announcement of some feature that was now working to hopefully rattle the other.
In the morning the other student system programmer/admin, Norman Wilson, got in and saw what Karl and I had been up to.
Norman mentioned this in an email to Rob Pike. His response was something close to this:
> Everyone writes a screen editor. It's easy to do and makes them feel important. Tell them to work on something useful.
It was only a couple years or so later that Rob Pike wrote a screen editor. I wonder if it made him feel important? :-)
Yes, who would have guessed that the <textarea> element, designed specifically for this use case and built into browsers for 3 decades, would be the most performant and behaviorally consistent way to implement editable text.
I'm kind of sad the author stopped shedding unneeded complexity there though... we're not really building a text editor yet, we're building a website with a fancy input field. If we want to build a proper text editor we must eschew the bloat that is the web browser too.
The browser-standards-or-bust moment has past, hasn't it?
If you want your app to work the same way across platforms, using browser defaults is not the way to achieve that.
If you want users to have a consistent experience within their browser across the web, I get it, but that's not how the Web has worked for a long long time.
Text editors are like mechanical watches or fountain pens. There is just so much beauty in the machinery that makes them. For me, there are hardly any other modules that are this satisfying to watch being made. Each time I find a new one (a good one like this), with everything on ropes and rendering and I-beam placement computations and ... it feels like a Christmas gift.
On one otherwise tranquil morning Master Foo's meditations were disturbed by cries of distress.
Finding that they came from one of the novices, he inquired "What is the difficulty here?"
The novice replied, "I am frustrated by my tools. Every day I must use many different editors because neither Emacs nor vi nor any of these other random editors has all the features I require."
Master Foo nodded. "How," he asked, "would a master of the Great Way resolve this difficulty?"
The student thought for a few moments, then replied. "Well, it's obvious. I will write the best editor ever. It will do everything I need. It will do everything everyone needs. And the world will be a better place because..."
The novice's speech halted as Master Foo rapped him sharply across the back of the head with his staff.
"Um. Master?" the student asked, rubbing the back of his head gingerly. "In what way have I erred?"
"Fool!" said Master Foo. "Do you think I want to learn yet another editor?"
Upon hearing this, the novice attained enlightenment.
Literally I only praised and wrote how much I love something and how beautiful text editors are. And there are people who cannot stand this :))) oh wow!
On text editor related topics, you should have thrown down the gauntlet and been explicitly clear that emacs rules, vi sucks, spaces are supreme, tabs are terrible, and mixing them is miscegenation. That way you only offend evil people, so their downvotes are delightful. Revel in them instead of whining!
Since you enjoy beautiful machinery, here are some classic clockworks:
A word of unsolicited advice: HNers are a prickly lot and will downvote without explanation because you stepped on some unknowable pet peeve of theirs that probably nobody else in the world shares. This happens all the time but you likely only notice when you happen to get downvoted before any upvotes and end up at 0 or -1. If your comment is reasonable, it will usually come back up.
But complaining about downvotes will certainly earn more of them.
It's unfortunately all too easy to hit the downvote arrow when you're aiming for the other one, especially for people using touchscreens.
I don't know who thought it was a good idea to put those character-size icons on adjacent lines, or who thinks it's a good idea to leave them there, but... this is one of those cases where it's better to assume it's an accident rather than an attack.
It's also true that there are a lot of asshats^H^H^H^H^H^H^H empty boats around here, but the above advice still applies, I think.
i didn't downvote it but I thought it was pretty empty. "how do i love thee, let me count the ways" has been done before, and his love was more interesting than that you like text editors generically, and you don't mention anything you like. I'm not in favor of more poesy in tech circles.
i like text editors but I feel they contain "everything but the kitchen sink" (if you know you know) and that makes them somewhat impenetrable and difficult to modify and bend to new purposes even though they contain so much capability and potential, and the people who do understand them think it's a good idea to drag and drop an URL and have that do a web transaction and download a buttload of text, when what I wanted was just the text... of the url. I'm sure there's some way to turn it off, but instead there should be some way to turn it on. Oh yeah, worse when it's a jpg url, guess what they do with that.
in another direction, the point of markdown was to be editable and readable in source form, not to be a replacement for rendered HTML, but the same people who ruined HTML by overloading it are now fully engaged in ruining markdown by overloading it and making it unreadable in source form.
I still don't see a point in switching from Sublime to VS Code. If I need to SSH in to my server, I have options there. But Sublime does everything I need it to do and it does it faster and cleaner and just better than the alternatives.
I've also been building my own editor - it's been fun. In my case it's a modal editor, so I ended up rendering with <div>s, but using a <textarea> to capture from the clipboard.
Around 2001 when I started getting into Linux seriously, I was also reading a lot about cults - Scientology had recently, infamously, forced Slashdot to take down a comment about their secret practices.
One of the things I read was that a common cult trick was to demand that people re-learn basic skills so that they do them the "right" way, like reading (Scientology did that), eating (chew X times!), using the phone etc.
So here's this system that demands I need to learn basic text editing all over? Nope, not joining that cult! We Amiga kids had had graphical editors for a long time!
So I got the best modern text editor Linux had at the time, NEdit from fermilab. It was almost entirely CUA + the conventions we use today (which aren't entirely what we used in 2001). And the unusual features it had, such as square selection and X-style middle click copying, were quick to pick up. It was also tiny, both in binary size and memory footprint.
Sadly it didn't really survive the switch to utf-8. I switched to Slava Pestov's Jedit for many years, and did some cool things with its huge library of extensions. But when VSCode started doing IDE stuff better than most IDEs, I defected to that. Yes yes, electron, Microsoft, I know... but it's just so damn convenient.
This is both the blessing and the curse of terminal based interfaces (I don't like to say TUI anymore since it makes me think of bubbletea style programs now). The curse being that there is way too much initial learning of how to use it (not that much, you can get by with half a dozen vim keys for years - I used vim for a decade before learning yank) but enough to be frustrating at first. The blessing is that once you master the basics they are very quick and very powerful.
GUIs are more intuitive but the options have to be visual so they are always cluttered in my opinions. For most software it doesn't really matter but I want my text editor to let me type without latency or visual clutter and almost nothing else is anywhere near as important. I've tried GUIs many times (vscode, sublime, atom, zed, bbedit, intellij) but I always end up back in vim with CLI git to the point that I get asked in screen share sessions to just use a GUI.
I literally just got Fable to write me a text editor. Well, I'll be honest, I got it to wrap the KDE KTextEditor library which is like 90% of a text editor.
I had been using Kate which was what an LLM suggested was the closest to something like Sublime Text on Fedora. But even Kate, which was great, had too much going on.
So I asked Fable to take the text editor part (KTextEditor) and wrap it using Rust with an LSP server. It took about 2 days but I have a tiny, super fast little editor. I use Sway to manage things like tabs, fuzzel stands in for fuzzy file search, broot stands in for an explorer view. I've already added Markdown preview support. I might get around to some basic git integration.
Then I got it to turn that little editor into a note-taking interface that I have bound to a Mod-m key binding to keep notes in ~/Notes.
We live in wild times. I hope everyone is taking advantage while they can.
> We live in wild times. I hope everyone is taking advantage while they can.
I dunno, hey. I'm not about to yolo my way for all things that are important. For things that are unimportant I will just use the existing stuff.
The goldilocks zone (things that an irritation, but not important), sure, I'll vibe a little Python/shell whatever, but pre-LLMs, I was already reducing my friction with little scripts anyway.
For example, in a recent comment of mine I posted a little wish script that I created in 2002, to have a simple GUI mp3 player, which I have been using daily since 2002.
> We live in wild times. I hope everyone is taking advantage while they can.
Yep, I'm taking advantage of the times by using the exact same tools I have been for years, and if those fail me, I'll pay for one of the multitude of other high quality editors offered by companies who's business it is to make them, so I get back to writing things in them instead of paying even more to companies trying to persuade me to believe that those products are obselete.
No shade on keeping using what is working. I was moving from Windows to Linux Fedora so I was in the market for a new editor. VSCode just wasn't working for me any more.
I considered a bunch of options, including vim or neovim or lazyvim, emacs, newer projects like zed. LLM gave a few more I can't recall including helix and Kate. There are so many good options these days, we're all spoiled for choice.
But the main thing is, and YMMV, I am not writing a lot of code anymore. I'm mostly reading/searching/navigating. So all of the powerful editing features are lost on me. No editors really match my current workflow, they all have too much.
So this was an opportunity to try something out, to experiment. See if I could do the real-deal vibe coding thing and judge the result. I just said "I want it to do ..." and then a few minutes later it did. I repeated this until it did enough to use as my primary editor.
I don't recommend it for anyone else, nor do I expect people to agree. Just describing my thought process.
What features did you end up implementing? I assume tree-sitter based highlighting, lsp, and maybe fuzzy search? Did you implement anything different that you didn't get out of existing editors that you tried?
Very few features on purpose. Every editor I tested had all the features I added and more.
It is worth noting that KTextEditor is a fully-featured library. Like, line numbers+gutter (for eventual git status icons), undo/redo, save, warn on exit for unsaved changes, syntax highlighting, color theming. It does 95% of what we'd all call "editing". But it doesn't do things like tab interface, project explorer, terminal pane, output windows, etc.
What the library didn't have were LSP features, of which I only implemented a few (error squiggles under things that fail the type check, go to definition). Notable absent are completions and hover features for things like help. I also only added (and tested) LSP servers for typescript, Rust and Go.
My plan has been: do as little as possible until I need something, then ask Fable to add it.
edit: I guess one thing I added I didn't see everywhere else was a built-in Markdown preview. But many editors have that (VSCode definitely does) so it isn't special.
I was planning to. It is 100% vibe coded, the first project I did that way. I'm one of those who've been reading all the code in my major projects. But when I got frustrated with editors and off-handed mentioned to Fable something like "I like Kate, but it has way too many option I will never use" it told me that the core part could be wrapped pretty easily (like 50 lines of C++).
So I just said "do it" and have been merging everything without reading a single line. It wrote all the specs, wrote all the code, wrote all the tests. I just got it to write out a tutorial to take me on a tour of the code it wrote, but I haven't reviewed it yet.
I will push it as OSS once I've made sure it hasn't included anything that I don't want public. But it wouldn't be super useable for anyone else since many of the features (e.g fuzzel and broot) are glue that exists in the Sway configs and some helper scripts.
It's held together by bubble gum and scotch tape. But is does exactly what I want and so far without a single bug, crash or problem. It's my frankenstien editor and I love it. (disclosure: I've been using it for less than a week)
It's obviously not for everyone, but if you fork that repo and prompt your favorite model to make it look and feel like you want, you can get something extremely useful very fast.
Hope the author finds CodeMirror 6 to be a solid foundation. It uses the same contenteditable-based approach but abstracts away all the browser-specific edge cases and quirks for you.
I am being pushed to use vs code right now by my team, but we already have a fully programmable and scriptable editor called emacs that is 100000x better. I don't understand why everyone just switches to these random tools. Text editing is a solved problem. Most of the supposed advantages of these tools is just a configuration of vim or emacs.
I use emacs daily (with vim keybindings of course), but I completely understand why vscode is so popular. It's extremely easy to get started with, has features galore, and sane defaults. Emacs takes much more effort to get productive with, although this is improving with each release.
In general, I find that good defaults are rather undervalued and downplayed in the FOSS world.
Configurability is great but without good defaults it can also be a liability. Would-be users will bounce off long before they like the software enough to pore through pages of options.
If you work on web tech (and who doesn’t these days?) VS Code has the advantage of using the same tech stack you’re already familiar with. If you need to debug a problem, just open devtools. If you want to run a performance profile, do the same. If you want to fix a bug in the extension you’re using, just open a PR and fix it.
It is a very flexible system and still quite fast and easy to configure. I’ve been trying Zed and WebStorm looking for better alternatives, but it turns out they have their own problems. Zed isn’t nearly as configurable, WebStorm’s config system is an absolute nightmare (xml for days - and constantly changing, mingling actual config with transient state).
People complain that VS Code is slow; perhaps on some metrics and perhaps it is slower than a much less featured system like sublime. But I don’t think it is meaningfully slower in practice than Zed, and they make a lot of compromises to get that edge.
VSCode's problem isn't that it's slow, it's that it's bloated. It takes a bit over 1GB memory (in my testing) to open the same files that Sublime can do in just 200-300 MB. In my book, it is simply not acceptable to waste my memory like that.
I’m trying to phrase this to not be “that guy” but have you used Code on large code bases? Vscode on my m2 Mac routinely crashed when doing file search. That is why I switched to zed.
That’s easy. Because if they accept that emacs is good enough, they have to then accept that probably whatever thing they’re building is almost certainly worthless.
26 different browsers all based on Chromium, 127 different “observability platforms” etc.
So so much redundant rehashed stuff. We can’t accept that though, THIS TIME it’s going to be great and amazing and we’ll get a huge investment and sold to a huge company for millions.
I’m not suggesting that it hasn’t been a huge leap in computing and software in the last 40 years.
But we need to have faith in new being better to keep going. That’s why the new hotness is always so popular.
They jump to such tools, because they are not that invested in making and having the optimal tool for their job, and don't want to spend time setting things up. Especially, not in their own time, if they even do any projects in their own time at all. Lots and lots of people in IT are not that dedicated or passionate about the work.
Because very few people actually care about the things that emacs has to offer.
Tools like VS Code do the job well enough for the majority of people, with just enough configurability and much greater ease-of-use.
Emacs has a similar problem to Lisp: Infinite configurability and expandability (plus the lack of a "blessed set" standard that people actually like enough to use out-of-the-box) means that everyone's environment and tooling ends up becoming incompatible with each other.
The problem with writing an editor if you intend to use it for coding, is not the text editor itself, that's rather simple. The problem is code completion and syntax highlighting. Then whatever system you try to implement becomes just as bloated as the bloatware you're trying to replace.
You can prompt yourself all the way to that. I don't have remote editing in my custom IDE because I never need that personally, but LSP/DSP, syntax highlighting, a built-in lazygit clone, git blame, soft wrap, find-in-files, etc all there: https://github.com/boxed/TurboKod
By "LSP support" I didn't mean "editor should call this API over HTTP and interpret whatever LSP server responds". It's a lot more than that, and LSP support in editors if often times broken.
It's like saying that editor can have full AI support because it can send HTTP requests to an MCP server. But MCP server isn't the end of the problem, it's just a gateway to problems, just like LSP.
For example, jdtls is often times broken, clangd sometimes works, sometimes doesn't. Language servers for ruby are a pain to set up. Some time ago LSP for Dart/Flutter worked under vscode, but not in Vim, because Vim had different assumptions how files should be reported to the LSP. Sometimes is the fault of the server itself, but sometimes the editor isn't fully compatible with some particular LSP server's quirks. It's a mess.
Rob Pike was the system programmer/admin before me when he was a grad student in high energy physics, but he left to go work at Bell Labs.
One day another student, Karl Heuer, and I both were engaging in the common programmer pastime of complaining about the screen editors of the day and saying we could write something better.
Somehow this turned into a competition, and we both spent all night racing against each other writing our editors. It was mostly silent except for the typing, interrupted by the occasional announcement of some feature that was now working to hopefully rattle the other.
In the morning the other student system programmer/admin, Norman Wilson, got in and saw what Karl and I had been up to.
Norman mentioned this in an email to Rob Pike. His response was something close to this:
> Everyone writes a screen editor. It's easy to do and makes them feel important. Tell them to work on something useful.
It was only a couple years or so later that Rob Pike wrote a screen editor. I wonder if it made him feel important? :-)
I'm kind of sad the author stopped shedding unneeded complexity there though... we're not really building a text editor yet, we're building a website with a fancy input field. If we want to build a proper text editor we must eschew the bloat that is the web browser too.
If you want your app to work the same way across platforms, using browser defaults is not the way to achieve that.
If you want users to have a consistent experience within their browser across the web, I get it, but that's not how the Web has worked for a long long time.
On one otherwise tranquil morning Master Foo's meditations were disturbed by cries of distress.
Finding that they came from one of the novices, he inquired "What is the difficulty here?"
The novice replied, "I am frustrated by my tools. Every day I must use many different editors because neither Emacs nor vi nor any of these other random editors has all the features I require."
Master Foo nodded. "How," he asked, "would a master of the Great Way resolve this difficulty?"
The student thought for a few moments, then replied. "Well, it's obvious. I will write the best editor ever. It will do everything I need. It will do everything everyone needs. And the world will be a better place because..."
The novice's speech halted as Master Foo rapped him sharply across the back of the head with his staff.
"Um. Master?" the student asked, rubbing the back of his head gingerly. "In what way have I erred?"
"Fool!" said Master Foo. "Do you think I want to learn yet another editor?"
Upon hearing this, the novice attained enlightenment.
—from The Rootless Root (https://www.catb.org/~esr/writings/unix-koans/index.html)
Since you enjoy beautiful machinery, here are some classic clockworks:
https://news.ycombinator.com/item?id=44633225
https://donhopkins.com/home/documents/EmacsRedisplayAlgorith...
https://donhopkins.com/home/archive/emacs/skull-and-crossbon...
https://donhopkins.com/home/archive/emacs/mw/display.c
https://donhopkins.com/home/code/emacs.ps.txt
https://donhopkins.com/home/archive/NeWS/news-tape/utilities...
But complaining about downvotes will certainly earn more of them.
All your best stuff will get downvoted by at least somebody eventually. For some reason, that somebody always gets in early enough that you notice.
1. Being near the top of the page
2. Having a downvote already
You can curtail the bandwagon effect by complaining.
I don't know who thought it was a good idea to put those character-size icons on adjacent lines, or who thinks it's a good idea to leave them there, but... this is one of those cases where it's better to assume it's an accident rather than an attack.
It's also true that there are a lot of asshats^H^H^H^H^H^H^H empty boats around here, but the above advice still applies, I think.
i like text editors but I feel they contain "everything but the kitchen sink" (if you know you know) and that makes them somewhat impenetrable and difficult to modify and bend to new purposes even though they contain so much capability and potential, and the people who do understand them think it's a good idea to drag and drop an URL and have that do a web transaction and download a buttload of text, when what I wanted was just the text... of the url. I'm sure there's some way to turn it off, but instead there should be some way to turn it on. Oh yeah, worse when it's a jpg url, guess what they do with that.
in another direction, the point of markdown was to be editable and readable in source form, not to be a replacement for rendered HTML, but the same people who ruined HTML by overloading it are now fully engaged in ruining markdown by overloading it and making it unreadable in source form.
They don't make 'em like Sublime Text anymore - https://news.ycombinator.com/item?id=49209354 - Aug 2026 (13 comments)
Is the experiment seriously rendering continuously in a loop?
I've also been building my own editor - it's been fun. In my case it's a modal editor, so I ended up rendering with <div>s, but using a <textarea> to capture from the clipboard.
https://github.com/joefreeman/aether
Around 2001 when I started getting into Linux seriously, I was also reading a lot about cults - Scientology had recently, infamously, forced Slashdot to take down a comment about their secret practices.
One of the things I read was that a common cult trick was to demand that people re-learn basic skills so that they do them the "right" way, like reading (Scientology did that), eating (chew X times!), using the phone etc.
So here's this system that demands I need to learn basic text editing all over? Nope, not joining that cult! We Amiga kids had had graphical editors for a long time!
So I got the best modern text editor Linux had at the time, NEdit from fermilab. It was almost entirely CUA + the conventions we use today (which aren't entirely what we used in 2001). And the unusual features it had, such as square selection and X-style middle click copying, were quick to pick up. It was also tiny, both in binary size and memory footprint.
Sadly it didn't really survive the switch to utf-8. I switched to Slava Pestov's Jedit for many years, and did some cool things with its huge library of extensions. But when VSCode started doing IDE stuff better than most IDEs, I defected to that. Yes yes, electron, Microsoft, I know... but it's just so damn convenient.
GUIs are more intuitive but the options have to be visual so they are always cluttered in my opinions. For most software it doesn't really matter but I want my text editor to let me type without latency or visual clutter and almost nothing else is anywhere near as important. I've tried GUIs many times (vscode, sublime, atom, zed, bbedit, intellij) but I always end up back in vim with CLI git to the point that I get asked in screen share sessions to just use a GUI.
It's all personal preference
I had been using Kate which was what an LLM suggested was the closest to something like Sublime Text on Fedora. But even Kate, which was great, had too much going on.
So I asked Fable to take the text editor part (KTextEditor) and wrap it using Rust with an LSP server. It took about 2 days but I have a tiny, super fast little editor. I use Sway to manage things like tabs, fuzzel stands in for fuzzy file search, broot stands in for an explorer view. I've already added Markdown preview support. I might get around to some basic git integration.
Then I got it to turn that little editor into a note-taking interface that I have bound to a Mod-m key binding to keep notes in ~/Notes.
We live in wild times. I hope everyone is taking advantage while they can.
I dunno, hey. I'm not about to yolo my way for all things that are important. For things that are unimportant I will just use the existing stuff.
The goldilocks zone (things that an irritation, but not important), sure, I'll vibe a little Python/shell whatever, but pre-LLMs, I was already reducing my friction with little scripts anyway.
For example, in a recent comment of mine I posted a little wish script that I created in 2002, to have a simple GUI mp3 player, which I have been using daily since 2002.
Yep, I'm taking advantage of the times by using the exact same tools I have been for years, and if those fail me, I'll pay for one of the multitude of other high quality editors offered by companies who's business it is to make them, so I get back to writing things in them instead of paying even more to companies trying to persuade me to believe that those products are obselete.
I considered a bunch of options, including vim or neovim or lazyvim, emacs, newer projects like zed. LLM gave a few more I can't recall including helix and Kate. There are so many good options these days, we're all spoiled for choice.
But the main thing is, and YMMV, I am not writing a lot of code anymore. I'm mostly reading/searching/navigating. So all of the powerful editing features are lost on me. No editors really match my current workflow, they all have too much.
So this was an opportunity to try something out, to experiment. See if I could do the real-deal vibe coding thing and judge the result. I just said "I want it to do ..." and then a few minutes later it did. I repeated this until it did enough to use as my primary editor.
I don't recommend it for anyone else, nor do I expect people to agree. Just describing my thought process.
It is worth noting that KTextEditor is a fully-featured library. Like, line numbers+gutter (for eventual git status icons), undo/redo, save, warn on exit for unsaved changes, syntax highlighting, color theming. It does 95% of what we'd all call "editing". But it doesn't do things like tab interface, project explorer, terminal pane, output windows, etc.
What the library didn't have were LSP features, of which I only implemented a few (error squiggles under things that fail the type check, go to definition). Notable absent are completions and hover features for things like help. I also only added (and tested) LSP servers for typescript, Rust and Go.
My plan has been: do as little as possible until I need something, then ask Fable to add it.
edit: I guess one thing I added I didn't see everywhere else was a built-in Markdown preview. But many editors have that (VSCode definitely does) so it isn't special.
So I just said "do it" and have been merging everything without reading a single line. It wrote all the specs, wrote all the code, wrote all the tests. I just got it to write out a tutorial to take me on a tour of the code it wrote, but I haven't reviewed it yet.
I will push it as OSS once I've made sure it hasn't included anything that I don't want public. But it wouldn't be super useable for anyone else since many of the features (e.g fuzzel and broot) are glue that exists in the Sway configs and some helper scripts.
It's held together by bubble gum and scotch tape. But is does exactly what I want and so far without a single bug, crash or problem. It's my frankenstien editor and I love it. (disclosure: I've been using it for less than a week)
It's obviously not for everyone, but if you fork that repo and prompt your favorite model to make it look and feel like you want, you can get something extremely useful very fast.
Configurability is great but without good defaults it can also be a liability. Would-be users will bounce off long before they like the software enough to pore through pages of options.
It is a very flexible system and still quite fast and easy to configure. I’ve been trying Zed and WebStorm looking for better alternatives, but it turns out they have their own problems. Zed isn’t nearly as configurable, WebStorm’s config system is an absolute nightmare (xml for days - and constantly changing, mingling actual config with transient state).
People complain that VS Code is slow; perhaps on some metrics and perhaps it is slower than a much less featured system like sublime. But I don’t think it is meaningfully slower in practice than Zed, and they make a lot of compromises to get that edge.
I do miss the configurablity though
So which one?
26 different browsers all based on Chromium, 127 different “observability platforms” etc.
So so much redundant rehashed stuff. We can’t accept that though, THIS TIME it’s going to be great and amazing and we’ll get a huge investment and sold to a huge company for millions.
I’m not suggesting that it hasn’t been a huge leap in computing and software in the last 40 years.
But we need to have faith in new being better to keep going. That’s why the new hotness is always so popular.
Tools like VS Code do the job well enough for the majority of people, with just enough configurability and much greater ease-of-use.
Emacs has a similar problem to Lisp: Infinite configurability and expandability (plus the lack of a "blessed set" standard that people actually like enough to use out-of-the-box) means that everyone's environment and tooling ends up becoming incompatible with each other.
Get off my lawn.
It can be used in headless-mode, I've hooked it up to the latest JavaFX text editing component it works very nicely.
[0] https://github.com/phronmophobic/clobber
It's not about the style of cursor, or if rope is used or not. We already have answers to that.
It's about remote editing, LSP support.
It's like saying that editor can have full AI support because it can send HTTP requests to an MCP server. But MCP server isn't the end of the problem, it's just a gateway to problems, just like LSP.
For example, jdtls is often times broken, clangd sometimes works, sometimes doesn't. Language servers for ruby are a pain to set up. Some time ago LSP for Dart/Flutter worked under vscode, but not in Vim, because Vim had different assumptions how files should be reported to the LSP. Sometimes is the fault of the server itself, but sometimes the editor isn't fully compatible with some particular LSP server's quirks. It's a mess.