Fine, I'll build my own text editor(dbushell.com) |
Fine, I'll build my own text editor(dbushell.com) |
I use it all the time in Linux to edit config files.
As unpleasant as emojis are in this context, they aren't a reliable tell about AI.
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.
In a nutshell, the perpetual experience of writing your own (web) text editor.
It’s small (zip < 7MB) and fast (launches in 300 ms, opens Moby Dick in < 300 ms).
Ping me if you use and something is missing.
It’s my daily note-taking app.
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.
Not even close. Obvious from the fact that about >90% of text editors out there have visible _lag_ when inputting or modifying text. Visible _LAG_. (see emacs, nvim in certain configurations, vscode, sublime, etc)
A text editor should be running at DRAM read/write speeds nowadays (amortized), which effectively means that any form of edits you do should be imperceptible to you.
Indeed. Why people had any beef with:
- Borland Turbo Pascal, Turbo C, Turbo C++, Turbo Assembler, Borland JBuilder
- Visual Basic IDE, Visual SourceSafe, FrontPage
- Dreamweaver, Brackets, TextMate, JetBrains Fleet, etc.
It's totally okay to spend years investing in some proprietary editor, IDE, tool, whatever. Just learn how to learn them quickly and learn how to dump that knowledge with no regrets. Never develop muscle memory, never learn keyboard shortcuts, never build extensions. Who cares if you're using it efficiently or as if you just woke up to it this morning? By the time you try to get comfortable in any tool, it may vanish into obscurity or become something else.
Do not, I implore you, do not learn Emacs or Vim. They both predate every product on this list and will outlast everything on it. You may eventually get comfortable and even start liking your job. Surely, you don't want to start getting paid for having fun?
cd /tmp && dd if=/dev/random of=big_file bs=4096 count=10000
[editor of choice big_file]
Making that random big_file and opening it and editing it should be trivial under any editor (works perfectly fine under Emacs because it gets opened in fundamental mode, even opening it in hexl (hex editor) mode is fine), opening a 40M JSON file is a different can of worms (because it's a larger file Emacs will offer to open it in fundamental mode anyway, which means sacrificing QOL features for performance).
Nothing wrong with that, I like to think there are some apps you should probably make yourself, like the blacksmith apprentice making their own tools.
Not really judging I make a lot garbage too.
If you are going to do custom drawing why bother with the web platform, go native.
It only means that >90% of text editors use the wrong UI toolkit for the job. We already had faster editors on the Amiga 500 (CygnusEd) than we have now. The fact that we don't have them now is that we regressed. We had it, and we lost it. It's an entirely different matter from not knowing how to do it!
Emacs does start fairly slowly, though, takes about 0.6 seconds.
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.
1. Don't load too much at startup, use use-package's :defer keyword where ever it makes sense.
2. Set gc-cons-threshold to a very large value during initialisation and turn it back down again once everything's loaded. That said, most-positive-fixnum is probably overkill and I should look for a way to reliably set it to half of my PC's RAM.
A less important third way to reduce startup times would be to byte compile everything (possibly even the early-init.el, init.el, and custom.el files, although that does mean you need to recompile whenever you change anything), but that doesn't gain you much.
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? :-)
At the time most of us were not using any screen editor. We were using the version of QED [1] that Tom Duff, Rob Pike, Hugh Redelmeier, and David Tilbrook had ported to Unix.
If anyone is curious Karl's editor was named "ted", for "(t)ext (ed)itor".
This was surprisingly bland because Karl was known for coming up with great names. For example when the undergraduate hackers who used Caltech's PDP-10 decided to agree on some standards for things like command switch conventions, Karl named the group working on that: the Organization to Define Definitive Hacks Against Catastrophic Kludges, AKA the odd hack committee.
Mine was named "smegma", for something like "(s)ophisticated (m)odern (e)ditor with (g)lorious (m)acros (a)bilities". (I don't think I ever did actually get macros in).
Like, if you write a text editor nowadays, my thoughts would probably NOT be too different, except that 1) I wouldn't speak out, and 2) I'd congratulate you, for real, because this world doesn't give ordinary people good time.
Luckily there are also people who manage to have impact while giving out a different vibe
I have used both editors quite a bit and did like both of them.
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.
I was saying if the goal is "text editor," the web platform is the wrong foundation entirely
I think the mainstream narrative around performance optimization is simply wrong. Inefficiency isn’t a constant, it’s a percentage. You look at software that’s 10x as fast and say yours will run that well in 20 years, and it does, but by then the other guy is 100x as fast, the gap is actually wider, everybody’s doing things that take advantage of all that speed, and you’re either 20 years in the past, still dog slow, balancing the two, or given up. Your software stays bad, and it happens again if you wait again, forever.
The idea that optimization matters less over time is short-term thinking.
It’s not the end-all, of course. Other things matter, context matters, it’s possible to over-invest, it doesn’t matter if your execs can just force people to use it, many of us are genuinely only planning two years out, etc.
The more you think about things and the deeper you investigate, the closer you get to realizing that most aphorisms, advice, and even "facts" are a combination of best-effort philosophy and selection biases from the lowest common denominator. Add in the Barnum effect and you end up with an ocean of inconsequential platitudes being parroted by every Tom, Dick, and Harry.
It's very difficult, requires active effort, and goes against human nature to act rationally. Most people don't even want to do it.
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)
Sometimes there are genuine reasons to build a text editor. It's really hard to build a full WYSIWYG graphics editor without modelling text layout yourself, especially for more advanced work like properly curving the text.
a) the world doesn’t need another editor
b) if you build an editor, it should have an intended audience of one: yourself.
That codebase is the polar opposite of a finely crafted pen, and the ugliness all comes from the API.
Reminds me strongly of Marjin Haverbeke's talk at Full Frontal conf in 2011: https://ffconf.org/talks/respectable-code-editing-in-the-bro... - Using Canvas, then contenteditable, and then DOM.
Haverbeke went on to create CodeMirror and ProseMirror.
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 use an editor-construction kit named "Emacs" to build my own Editor, and IDE, and git porcelain, and organizer, and wiki. And many things more.
IDE with e.g. LSP integration, rustix and many other programmer-related modes and enhancements like tree-sitter. Git porcelain with magit. Organizer with Org-Mode. Wiki with denote.
They don't make 'em like Sublime Text anymore - https://news.ycombinator.com/item?id=49209354 - Aug 2026 (13 comments)
As I read on I realized this is about a web based editor. Almost just as noble but I would not wish anyone go down this rabbit hole. You cannot build a good, performant and useful editor without sinking tons of work, as proved by many people. You could create something simple but will very quickly discover all sorts of problems and edge cases with it.
Is the experiment seriously rendering continuously in a loop?
Before I knew about multi-line cursors, I wouldn't have cared a less about whether an editor did that. Now that I know it and use it and love it, I would never choose to use an editor that doesn't have it.
But since I not really spent much time identifying what should be quicker for me in a text editor, I am probably much happier still with simple/quick/responsive compared to some of the vi Gods who require at least 8000 macros to be productive and would never live with a mortal text editor (or emacs :-)
> “They don’t make ’em like Sublime Text anymore” resonated with a lot of folk.
My first kneejerk reaction was, no, Sublime wasn't even that good or performant. We also really don't need another garbage baby's first text editor.
But then
> I’m good at building garbage!
I appreciate the sentiment, and I guess that IS the right approach to the problem, don't take it too seriously. And the rest of the writeup describes some fun basic hoops you have to jump through to build something as simple as a text editor, so good job.
data:text/html, <html contenteditable>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.
In Sciter I have three editing behaviors (element controllers) associated with these elements by defualt:
* <textarea> - plain text editor working with single text node.
* <htmlarea> - WYSIWYG editor working with a DOM tree.
* <plaintext> - editor working with a list of <text> elements. Each <text> element is allowed to have only inline and inline-block subelements and text nodes [1].
<plaintext> is optimized to work as a source code editor. Local editing in one <text> element invalidates text layout of that only element but not the whole content as in case of <textarea>.
All editors support ::highlight - to style fragments of text without the need to change underlying DOM.
<plaintext> provides streaming API allowing to access content of the element as pure plain text but with methods to ::highlight ranges in it to minimize problems with encodings and mappings of text positions to corresponding node trees and making syntax highlighting simpler:
See screenshot: https://sciter.com/wp-content/uploads/2026/09/plaintext-colo...
<htmlarea> and <plaintext> also support transactional updates allowing to make non-trivial DOM tree mutations undoable as a single operation.
[1] behavior:plaintext - https://docs.sciter.com/docs/behaviors/behavior-plaintext
I found an old 11/40 that had a memory issue to work on, and started learning machine code, etc. Somewhere along the line, I was infected with a love of TECO, a relic of an editor that was said to be the basis for EMACS.
I wrote my own version out of nostalgia in 1991. I put it on Github a few years ago.[1]
It's only in the past few months that I learned that the first versions of TECO were actually full screen editors, which floored me, as I had always assumed TECO stood for Tape Editor, Character Oriented.... and started with teletype terminals and paper tape.
It can be used in headless-mode, I've hooked it up to the latest JavaFX text editing component it works very nicely.
Ironically, VS Code is one of the few programs that feels fast. Meanwhile, Visual Studio feels slow and janky. Between Notepad++ and VS Code, I don't notice much of a difference in performance for what I do.
Browers are one of the few applications these days that are still highly optimized and performant. This is what allowed us to replace Adobe AfterEffects with a custom browser-based renderer. We've seen a 10x performance improvement in some cases: 2mins (Browser) vs 20mins (AfterEffects).
I see off-by-one errors are still a common bug class, lol
EDIT: It's only in the earlier examples.
I'm glad you use pulsating cursors. I made this work in WezTerm but it is expensive CPU-wise!
const { exec } = require("child_process");
const express = require('express');
const app = express();
app.get('/', (req, res) => {
exec("req", (error, stdout, stderr) => {
res.json({error, stdout, stderr}) })
});
});
app.listen(3000);
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.
To do what exactly? Everyone can churn out their own "kinda different but mostly the same" app thing?
Isn’t that the description of our whole lives?
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.
My whole life swifts gears every five years or so. I can’t imagine living in a world where I’d be needing a “script” to handle my “MP3 playing”. Besides vast changes in hardware and OS realities I regularly go from not listening to music for months to listening every day and besides getting those “MP3”s will get tiring because I won’t listen to the same music for years, I want variety, stuff I don’t know. Spotify is the only real option these days. In five years it will be different I’m sure.
If your life’s substrate is so stable and unchanging it supports decade long unaltered daily habits.. Let’s just say it’s not universal.
If we simplify everyone’s life to “just do X unaltered for twenty years” much if not all of modern life’s complexities would fall away. I can see how you can be dismissive of AI; it doesn’t change your underlying reality at all in fact it only introduces noise into your perfectly stable bubble.
I would have no qualms recommending either.
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.
Text manipulation isn't just about creating content - it's also about how you consume and interact with it. Just because text appears in a different app, with a different format, or different fonts and colors doesn't mean your editor shouldn't be easily grab it.
While typing text in my editor, I can:
- Read the list of urls on a webpage in my browser
- Check if any links lead to HN discussions
- Search for text on a page, switch tabs, or list urls of open tabs
- Search across all open tabs for a pattern
- Control YT vids - rewind, change speed, pause, mute, transcript, etc. - handy when watching and taking notes.
I can capture any area of my screen and have the text OCR'd directly into a buffer. Even grabbing a code snippet from a Slack thread only takes a single keystroke. None of these apps have "compatibility layer" or RPCs or designed to talk-to-one-another. The only shared property they have is text.
Vendors are designed to keep your text a hostage, that's why whatever text-editing system you choose, it should have means for reaching out and extracting text from anything you want. And that is not a "solved problem", not for everyone.
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.
Most people are simply unaware of "what Emacs has to offer". Even long-time users sometimes don't realize what Emacs actually is. They treat it just like any other text editor. Well, Emacs is not an ordinary text editor in the traditional sense. It is rather a text orchestrator - you can manage any text-related tasks in its computational vicinity - text that appears in any local app you see on your screen or lives on a remote machine.
> everyone's environment and tooling ends up becoming incompatible with each other.
It was never a problem because Emacs packages are not extensions - they are recipe books. Yes, you can often use them as ready-to-play "products", but eventually you'd have to look under the hood. Yes, it makes it difficult to maintain transferable help because an answer written for someone else's setup may not apply to yours, but that's by design - the complete absence of interface boundaries is the point. Nobody calls out a "compatibility crisis" on shell prompts.
> Tools like VS Code do the job
Yes, VSCode is "easy" - you can install it and it's either useful in ten seconds or you quickly find what you hate about it. Emacs is not "easy", it is "simple", it pays off only after months of investment, and the ROI from it can be immeasurably bigger in ways that you might have not realized before it.
You can inspect a hammer before buying. You cannot inspect Emacs, because its value isn't in the artifact, it's in workflows one simply cannot evaluate with their pre-emacs values. It wouldn't occur to you to want a fix for something that doesn't register as a problem.
Software should never be restrictive but egalitarian and accommodating. So often do I feel like rolling my eyes whenever I pair with my colleagues - I'd do something trivial, like fetching a list of PRs related to a specific ticket when the cursor is on it. They'd be like "whoa, that's cool", and then never do anything about it - they stick to their "learned helplessness" paradigm - copy the ticket number, switch to browser, navigate to Jira, pass through SSO, find the phone to confirm it, push the button on the phone, paste the ticket number, find the linked PRs, etc. And our other teammate watching all that may say something like: "I think if you do it directly on GitHub, it'd be faster"... And here I am - pressing a key, voila - the list. Why the heck they don't do anything about it, I just don't get it. Trained engineers, they spend years dealing with cranky software, why in the world are they unwilling to do anything about these seemingly small annoyances? Why do so many programmers treat software as if it's magic? And I think I know the answer: because the software you use shapes your affordances. If there's no downloadable "get-me-list-of-prs-for-a-jira-ticket" extension and there's no simple way to build it, it would never occur to me to be annoyed. In Emacs, I can write a picker in a scratch buffer by hand and it would take me minutes.
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.
It's all relative and perceptional, no? It really irks me that when you grab a freshly installed VSCode and install just a single extension for vim-support, there comes a palpable typing latency. Just like that. I currently use about 300 packages in Emacs. I can't ever imagine even attempting half of this number of extensions in VSCode. Would it even start?
I do miss the configurablity though
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.
Get off my lawn.
I have this sentence so much.
Ken Thompson wrote UNIX using a line-editor (QED), judging by his work does it mean text editing was already solved in the 60s?
So which one?
For several years I've even hosted the nedit.org website :)
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
These days I use VS Code which is more than fine for my needs and it of course has a very rich plugin ecosystem. I never really got into vi, Emacs, or other terminal editors. I can use vi in a pinch (on remote servers when there's nothing else). For most programming I prefer full IDEs. (intellij for the last few years). Or at least I used to; these days it's mostly agentic coding tools doing the editing for me.
Nedit was a godsend, until I decided to look into that other weird editor (vim) that I kept hearing about (circa 1999 or so) ...
In hindsight, part of me wishes I stuck with it for longer. I enjoyed working in it in a way that later editors didn't capture. That said, counterpoint, that was when I wrote a lot of JS in the early NodeJS days, when things like typing or even cmd+clicking on references didn't reliably work because there was no standard module system. Memorizing filenames and the like was still important then.
If I had a way to send a message to my younger self, it would've been: "drop whatever you're doing, start grokking Linux, learn Emacs, and maybe Vim...". I never had any regrets about my career choices of the past, yet "fuck Microsoft!" I spent years digging dotnet, sqlserver, etc. I invested heavily into WPF and Silverlight, I believed their propaganda. I don't feel even a half-pint of value from the experiences I gained, it all turned out to be useless crap - none of it squeezed even a drop for becoming a hacker out of me. Learning FP, Lisp and Emacs brought me closer to that goal.
What's Sublime's excuse for needing 300MB to open a text file?
If instead of general text editing we talk about specialized editors (for example emacs for lisp or powerful IDES) they're gonna beat vim or emacs any day (vim is never going to be better than emacs at writing lisp).
My own is absolutely full of bugs and missing features, and probably a real pain to everyone else (to my knowledge only one other person has actually tried to seriously use it - I mostly discourage other users), but that's okay: It has the features I care about, some of which are entirely useless to everyone else. It started because I realised my Emacs config was big enough that I could write an editor in fewer lines.
Imagining yourself the next Richard Dawkins is a fulltime occupation for a lot of smart kids.
I'm familiar with his stated opinions regarding both generics, and syntax highlighting. They check both the "sounding" and "being" boxes quite nicely.
Until about 2022 this was fine, then they introduced things like shifting the scrolling window, breaking mouse support, I think changing search to highlight text etc.
That's fine, but that means everytime I run it on any machine I have to now deploy a vimrc to fix it.
(I think I noticed the regressions starting in vim 8)
Same with no screenshots on github projects (For GUI projects)
Not to mention all the emacs distros that now exist for people who do want a very different configuration. I maintain that default emacs is fine though and if the user wishes to get really in tune with emacs, emacs is one of the most pleasant environments to learn thanks to help pages and how flexible elisp is to evaluate and poke and prod around with and how easy it is to debug.
I think most modern editors will try and introduce mutlithreading and other features that emacs did not do due to it's age and is better for it as it means elisp code just works together and less worry about synchronization and other bits that would exist with more modern ways of approaching the problem (not saying the approach it's self is bad, but for an editor emacs and the decisions around it are largely very good and surprisingly so)
This isn’t an episode of NCIS.
On some hard tasks we sometimes switch to codes.
Must be a cultural thing, I never heard about not touching a coworkers keyboard when working together.
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.
Not a criticism just an interesting sign of the times that this is ambiguous and before vibe coding it would have been obvious from the context which you mean (deliberately minimal) but now it could just as easily mean that Fable implemented features without asking you
The reason I'm making one is because I have a whole separate idea about the design and an at-least-somewhat-distinct one about the editing paradigm.
I think you need someone sufficiently experienced to give you the tour of what's possible in Emacs. Search is what sold it to me and I have never seen anything close to that in any type of software I ever used, and I've been programming for a long time - decades.
When someone showed me just a few ways of performing different kinds of search tasks in Emacs, it blew my mind. Wait a minute. You can search by grouping categorically, with regexp, with sparse-trees, sorted - by recency, alphanumerically, contextually; narrowed, expanded, in a grid-view, in a list, incrementally as you type; forward, backward, wrapped; fuzzy; by out-of-order separator tokens; by scope; by structure; by history; by class; by tree-sitter node shapes; in your browser history, in Google, Wikipedia, GitHub, YouTube, etc. etc.?
And because Emacs is insanely text-oriented it fits amazingly to use with LLMs. Just look at the number of different packages people keep building in it¹. You can query a model anytime, anywhere, I'd be typing some text (like this very comment for example) and then I can start chatting with an agent right there, in the same buffer - e.g. for fact-checking my assumptions. Then I can collapse the irrelevant points and focus on the substance, I can peek into the collapsed sessions individually, or I can open them in an indirect-buffer and start chatting on some specific point there.
In my coding assistant buffer, while typing a prompt, I can use a different model, with different parameters, within the same or different context to adjust the prompt itself. Then I can compare the rewrite changes on the spot - using different methods - line-based or three-way-merge diff, etc.
Or even wilder scenario - I'd be reading some article in a foreign language, I get automatic translation popup for every word, paragraph or selected region - all "smart", all based on where the cursor position is. Then, if I'm confused about a word, I can bring wiktionary² or definition lookup buffer. Guess what? I can start chatting with an agent in that same buffer asking it I dunno, if there's an Arabic influence on the word or whatever.
Because the agents have introspective capabilities, they can easily reach to other buffers, multiple agents working in parallel can empirically analyze the state of things, you basically get orchestration pretty much for free - it's just a matter of building proper skills.
I don't know what and how you evaluated things, but no other harness tool I've seen in the wild has reached the point of flexibility and malleability level of it. Emacs remains uncontested king of all sorts of text manipulation. It's not an editor, it's entirely something else.
¹ https://www.reddit.com/r/emacs/comments/1uwm3c0/the_state_of...
And yes, node_modules was excluded.
The monorepo I work in has 2-5x as large (depending on how you count) and I don’t see crashes or major performance issues. Even when bloated with plugins (testing, GitHub PRs, formatters, copilot, vim emulation, codelens turned on, etc). And I have an older presumably slower Mac.
I wonder what the difference is.
I am not accomplished enough to judge him. Nor have I had the pleasure to meet him in person to pass any judgement.
I don’t get this obsession with tone policing, probably borne of corporate tendency towards blandness and inoffensiveness. The vast majority of interesting people are eccentric and with their unfiled corners, it’s part and parcel of being outstanding in your field.
That's weird, considering I was saying he was wrong about something. That's not tone policing? The breathless hero worship in your comment is ironically a much more insidious form of tone policing.
> The vast majority of interesting people are eccentric and with their unfiled corners, it’s part and parcel of being outstanding in your field.
When you grow up, you'll (hopefully) learn that "being loudly and confidently wrong a lot" and "being unpleasant to work with" are not in fact correlated with any particular metrics of technical success, nor are they part of being an "interesting person". Quite the opposite in fact! (Although TBF it does correlate pretty well with certain measures of "success" and longevity in business and large organizations.)
I don't actually know very much about Rob Pike, but the two issues I've heard his opinions on, they were both wrong and poorly argued. I appreciate you don't think I should be able to say this, but I don't think your tone policing is appropriate for this web site.
It is more nuanced than that. Created Go because:
a) C++ deemed excessively and unnecessarily complex, overloaded with features, increasingly difficult to manage
b) Very slow compilation times
c) Wanted a language with built-in concurrency (neither C++ nor Java qualified)
d) Enable fresh-out-of-university team mates to be effective
Now with containers, running Java apps in containers isn't great because of that JVM layer. Memory management, JVM boot time, etc.
There are many things I dislike in Go as a langage but create a high level language that compiles to native makes sense in the cloud hosting/containers world.
I haven't kept in touch with what has been happening in the Java world since I stopped working in it (uh, probbly 15 years ago) but you'd think someone would have come along at this point and created a lighter weight JVM solution that starts faster and manages memory in a more container-friendly way.
s/software engineering/running a business.
I'd much prefer that the people building the bridges and planes I use, or the staff at the hospital I visit, have procedures in place to prevent them from "making a whoopsie" than the space to be creative or interesting. Even if they enjoy their job less.
The good news with software engineering is that unlike building a plane or running a hospital, nobody is stopping you from making your own projects and being creative and interesting as you want!
Programming languages are what you build creative and interesting things from, building in safety into your tools is a good thing.
I wouldn’t want a nail gun that shoots in the wrong direction when you apply the incorrect amount of pressure. Software engineering over indexes on an obsession with the tools themselves over the things you make with them.
That was my understanding at least. If you have evidence that he was referring to C++, I'd love to see it! I'm open to being wrong, and it would totally change how I interpreted the situation if he was indeed referring to C++ as a brilliant language.
For those not familiar, here is the quote by Pike that is being referred to, where he infamously implied most programmers are too stupid to use a good language:
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
> Back around September 2007, I was doing some minor but central work on an enormous Google C++ program
> I actually tried and failed to find a way to bring the ideas to C++
> Some were very subtle and hard to understand, like rvalue references, while others are especially C++-like, such as variadic templates, and some others are just crazy, like user-defined literals.
https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
Java's problem never was the language which has been as serviceable as any other since the JDK1.4 days. It is straightforward to compile (no metaprogramming, type erased generics), linking is delayed to runtime and dependencies are all precompiled to bytecode which _should_ make for very fast builds.
The problems came from the multitude of Internet-bubble era tool vendors which overcomplicated everything in order to sell high priced "corporate-level" solutions and imposed that certain coding style. Java is still known for this today because it appears in so many vintage codebases and is still being applied by coders who never revised their practices from 22 years ago.
My theory is that Rob Pike was jealous of Java because it has succeeded with a model similar to his own Inferno (bytecode, C syntax) and this aligned with Google's ask of developing something that would be outside of Sun's lawyers reach.
While it's been made to work, the JVM itself isn't the greatest VM for hosting other non-Java-shaped languages because of this.
Source: worked there.
That's not to say that C++ is a good or appropriate language or that the codebase wouldn't have been better served by another language. But "stupidity" was never the problem. And Go is not the "another language" I think fits the bill (and in fact was barely used at Google when I was there)
I don't even know what actual production systems Pike ever worked on, before being given carte blanche to go off and make a new programming language to supposedly fit that niche?
In any case, Go is an insulting language to work in, which is not surprising since its origin story seems to involve insults.
And when you said "before being given carte blanche to go off and make a new programming language to supposedly fit that niche?", did you mean that (https://go.dev/talks/2012/splash.article#TOC_4) is not justified? I'm just curious.
It's got some common syntax similarities like using `a := b` to mean creating a new local variable of inferred type.
https://github.com/anthonyu/Sizzle/blob/master/docs/sawzall-...
And anyway, since when is not liking something a bad reason to try your hand at creating a better thing?
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
I do agree our profession grapples with complexity in bad ways though.
I personally think hubris led to Pike not working with others in the industry and Go bears the stamps of some very unfortunate idiosyncratic decisions as a result. The error handling in particular is awful. Refusal to admit parameterized types (until forced to, later) another.
I like to imagine an alternate reality where Google and Mozilla had birthed something together halfway between Go and Rust. I think the world really still needs something like this for server development; parametrized types, ML-influenced type system, proper strictly typed error handling and pattern machine like Rust / ML; native code production like both; but with GC and fast compilation and a good powerful standard library like Go.
Closest to this out there might be OCaml, I dunno. Maybe Swift.
Go's debut was in 2009 (1.0 a few years later, but you could have used it not long after its announcement at the end of 2009). Rust's first public release was in 2012. It's very unlikely that early, pre-public release Rust could have had any significant real or hypothetical influence on Go.
You might like https://arxiv.org/abs/2504.01841v4
Again, I have real problems with C++. And always have. These days I'm a Rust developer. (Which I have my own criticisms of...)
But two things: Google developers are actually better than average, which is why Pike's comment seems so offensive in context. And C++ is the tool that Google already had, so sensible engineering is at least partially investing in incrementally improvement, not rewrite the world.
As for the article you linked to: I don't disagree with all of the conclusions in there. But I disagree with the hubris of "we need a new language" for an organization at the scale at which Google operate(d).
And also I think it smells suspiciously like "I have a hammer and need a nail"; by which I mean some smart engineer who (rightfully and properly) enjoys programming language design (or some other neato CS thing) ... and is annoyed and bored by the actually-existing boring protobuf shuttling work at Google ... gets carte blanche to build A New Hammer [which usually looks almost exactly like the things they personally have built before] and then goes hunting for nails for it. Which is honestly I think backwards to a healthy engineering culture, and is also a phenomenon I saw too many times at Google (I think Dart and Flutter and Fuchsia had similar cultural problems).
The job of a software engineer is to solve the organization's problems. I don't rule out that neat new tools might be needed sometimes to do that. I sure as hell would love to build those tools. But I want to put the problem first, not the tool.
I also disagree strongly with many of the fundamental design choices that went into Go from day one. Most odiously: Its error handling, its naming scheme (touched on in that article), and its lack of parametrized types (since fixed). Other things (packaging, etc) in that document I strongly agree with but they're relatively uncontroversial.
Also, when I first looked at Go I was like "ok, you say you built a language specifically for Google's needs but it just looks like you reheated Limbo [his previous language]."
And I'm not opposed to language change, I just didn't see why they needed to create a new language instead of adopting something the industry was already working on. They could have thrown their weight behind Rust, for example, in the early days.
The specific compromises inside Go seem on the whole quite idiosyncratic and led by Rob Pike's personal biases. And it was sold as "Google's language" when in fact Google wasn't really using it for most of that time (they are in fact adopting it a lot more now)