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.

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.

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://smackernews.com/item/49209354 HN - 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 :-)

Fine, I'll build my own text editor

“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

https://pkg.odin-lang.org/core/text/edit/

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.

[1] https://github.com/mikewarot/teco

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

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!

I’m good at building garbage!

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

[...] is promising but I’ve noticed strange [...]

In a nutshell, the perpetual experience of writing your own (web) text editor.

https://qm.venka.com

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.

   cd /tmp && dd if=/dev/random of=big_file bs=4096 count=10000

   [editor of choice big_file]

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.