Last time, we took our first step in building a simple text editor: gathering references to understand how the problem might be decomposed. Let's dig into them! https://twitter.com/wasimlorgat/status/1309742880165158912?s=20

Finseth's The Craft of Text Editing is an excellent source for this! They suggest to decompose an editor into three sub-systems:

1. The sub-editor
2. User-oriented commands
3. Redisplay

1. You can think of the sub-editor as a bare minimum text editor. Its most important component is the buffer, which stores text in a way that enables efficient reading and editing. This isn't as straightforward a problem as it seems, but we'll get to that later

The buffer is no use without being able to point to specific locations. That brings us to the second component, the point, which moves through the text in a buffer, and which decides where in the text a given action has an effect

Finally, there are marks, which are like points, except that they're transient, and you can have many of them. The point of a mark (ha) is to define regions of text – between the point and a mark, which can also be acted on

2. Use-oriented commands: whereas the sub-editor exposes simple actions like InsertCharacter, these commands are more user-friendly, like LineToLowerCase. Finseth rightly says that its the user-oriented commands that give an editor its "feel"

In fact, there's no reason why two editors with vastly different philosophies (*cough* VIM/Emacs) couldn't share the same sub-editor and redisplay sub-systems

This sub-system receives user input and dispatches to a command, which then calls the necessary sub-editor methods. For example, C-x dispatches to Cut, which reads a region to the clipboard, deletes it, and moves the cursor to the mark (all of which are sub-editor methods)

3. After a command is processed and the text modified, redisplay efficiently updates the display to reflect the latest state of the data. Doing so efficiently is itself an interesting topic. I'll rely heavily on the curses package, which does a lot of that work for us

And there we have it, a high-level decomposition of text editors. Next time, we'll get cracking on the implementation!

Oh, I almost forgot. What's so interesting about text buffers?? https://twitter.com/wasimlorgat/status/1310275999712583684?s=20

Consider the naive solution: store a file's text in one long string. It's memory-efficient – if we never modify. But this is a text _editor_. When you insert a character you'd need to allocate memory to an entirely new string with the added character. Not great!

Text editors require sequences that have efficient insert, delete, and read at arbitrary locations. These locations, however, do tend to be localized – when you type, you insert characters in sequence. The solutions turn out to be interesting and unique data structures!