Joshua Kellogg

< back

What Must a Text Editor Do? (Friction devlog 1)

When can I get off of this ride?

created - changed 930b575

I’ve been writing a text editor called Friction off and on for about two months now, and I’ve decided that it’s actually really important for me to decide when it will be finished so that I can be finished with it. One reason for this is that as it turns out, writing a text editor is really hard. Don’t get me wrong, I’m having a blast! I got into this whole software development thing because I like solving hard problems, and the abundance of them that Friction has provided me with has felt like a real feast for my mind. That being said, with every day I work on it, the fact that there are only about five1 good text editors makes more and more sense to me.

The other reason is that I eventually do want to get a job doing software engineering. I don’t really mind being a barista, but I could (in theory) get paid a lot more to do a lot more interesting work, and I would like to pursue that. It might surprise you to learn that I don’t get a lot of inbound from recruiters as a full-time barista who never finished my CS degree (or any degree, for that matter), so the only way I’m ever going to manage that is by having some kind of proof that I can write working software. In short, finishing a project and moving on from it is the only way I can put any coding experience on my resume without straight-up lying.

So anyways, back to the topic at hand! What does a text editor need to do?

Selecting Text

Seems right, huh? I mean, you can’t edit text if you haven’t selected it, but when was the last time you thought about how you select text? One of the big differences between Neovim and something like a Kakoune or a Helix is that Neovim normally requires you to construct a selection in your mind after you’ve already decided what action to take.2 In contrast, Kakoune (and, from my understanding, Helix) primarily operate by constructing a selection you can see, and then deciding how to operate on that selection.

This seems like a small issue, but choosing the selection-first approach has made my life hell recently (as I’m sure I’ll write about later). I have to make lots of decisions just like this in order to establish when I can at least walk away from this thing, so we have to get a bit more broad with our requirements.

Getting a Bit More Broad with our Requirements

So, let’s try and define this in terms of what I can do with this editor before I can call it done. If the ceiling is feature parity with Neovim, then the floor is being able to author a commit to the editor’s repository in the editor. It may be the most painful pull request I ever submit in my career, because my time budget does not extend to syntax highlighting and a working LSP client, or even a file browser. Even with all of these caveats, this is still a pretty big lift, and reaching this point by the end of the month is going to be a pain to say the least.

So, what features still need to be added in order to support this lofty goal of making a pull request a la Apna College to my own repo?

Damn, brother.

At first glance, this seems like way too much functionality for a MVP, and it probably is. It’s also not even close to everything I expect out of a text editor; in fact, it’s probably not even a quarter of what I expect. To top it all off, it’s written in Go. Go is pretty fast but I’m also very sensitive to latency (The reason I don’t use Ghostty is because it’s way too slow to start up. Half a second doesn’t sound like a lot but the startup time for footclient is literally too fast to measure and there’s simply no going back from that for me), meaning this list leaves off the biggest and most difficult feature: be fast, even with pretty big files.

Let’s Kill Some Tickets

This leaves us with a hard question. Let’s just set ourselves a hypothetical deadline of Halloween. That doesn’t fill me with warm & fuzzy feelings given that I only have about 20 hours a week to spend on this, but let’s just say we can make it happen. What can we kill?

Instantly, most of the nice text-editing commands that make me want to actually use an editor are pretty much out the window. We can always add them later if the mood strikes us, but more text-editing features are good for nothing if we can’t decide what text to edit, or write those edits back to the file we’re editing. So, our new list looks something like this:

That feels… reasonable. I was really hoping to end up with an editor I would actually want to use for something but I don’t think I can accept the timeline that comes with. Maybe in the future I’ll rewrite Friction as a native editor, like the kind that renders fonts and stuff. It could be fun! For now, though, it’s in my best interests to commit to a finish line and then cross it, so that’s what I’m doing.

Conclusion

Congratulations, we’re all product managers now. Even with this stripped-back set of requirements, I think it would be overly optimistic to set a deadline anytime this month to be done with this whole project, so we’re probably looking at mid-late November. I have high hopes for that! There are at least 2 more topics I already want to write about before that, so look forward to those too. At least one of them will be coming out this month. Until then, safe travels.

  1. There’s more than five. I was going to make a list, but the bottom line is that Neovim would be on there because I use it and the rest would be arbitrary anyways. ↩︎

  2. Please don’t tell me about visual mode like I’m not literally writing this blog post in Neovim right now. I’m just trying to keep this thing brief, we can agree that visual mode in Neovim is not the same as normal mode in Kakoune, let’s all just move on with our lives. ↩︎

Tags: