Behind the scenes, "plain" text editing is unbelievably complex and weird

One of the most interesting things about programming is that it forces you to decompose seemingly simple ideas into a set of orderly steps, and when you do that, you often realize that the "simplicity" of things you deal with all day, every day, is purely illusory and that these are actually incredibly complex, nuanced, fuzzy and contradictory: everything from peoples' names to calendars to music, art, email addresses, families, phone numbers, and really, every single idea and concept.

It turns out that "plain" text is also fantastically complex. Alexis Beingessner's daunting list of the problems of text rendering makes that clear.

And once you've got the text to render, you have to edit it, and that turns out to be even harder, as Robert Lord describes in an essay recounting the lessons he learned spending several years merely implementing a text-selection library.

Jonathan Blow, in a talk about how software is getting worse, points to the example of Ken Thompsons text editor, which Ken built in a single week. Plenty of the code in this blog post is accidental complexity. Does Windows need 128 interfaces and 8 kinds of locks to provide text input? Absolutely not. Are the bugs weve found in TextEdit disappointing, and a result of a complicated editing model? Yes. Are the wealth of bugs in modern programs something we should be worried about? Im worried, at least.

But at the same time, Ken Thompsons editor was much, much simpler than what we expect from our text editors today.