6 Months of Rift6 Months of Rift | TJ Raklovits<br>Back to Blog6 Months of Rift<br>June 29, 2026<br>4 min read<br>By TJ Raklovits
ProgrammingRust
Click to enlarge
I have been a vim/neovim user for most of my programming life, which at this point means I've been programming for about 15 years and using vim or neovim for 10 of those, and in that time I have built custom vim configs in vimscript and then in lua when that became the thing to do, played with and tried practically every plugin in the ecosystem that seemed worth trying, used big vim distros like spacevim and lazy.nvim and astronvim for a while before inevitably getting frustrated with some opinion they had that wasn't my opinion and going back to something I'd assembled myself, and I have evangelized about vim for years to basically anyone who would sit still long enough to listen to me: coworkers, friends, people at meetups. I love it, genuinely, I think modal editing is the right way to interact with text and I've never really wanted to go back to anything else, but neovim is enormous and has hundreds of features that, while certainly useful at times, I mostly never use, and it has gaps that need to be filled with plugins which have their own opinions about how things should work and their own bugs and their own maintainers who may or may not still be around. At some point my editor started to feel less like mine and more like someone else's editor that I happened to have put a few hundred lines of lua on. I wanted something simpler, something that only has what I actually use, designed not to be an extension of everyone's thought about what an editor should be but specifically mine, something that works the way I work and has paradigms that make sense to me and where I can build the features I want without having to also carry around the hundred features I don't. I'd been reading Acme and abont with interest for the same reason, editor concepts that had different dissatisfactions.
So in December 2025 I started writing rift, first in Zig because I wanted to learn Zig and had been looking for an excuse to, and an editor felt like the right kind of project for that: big enough to be a real project with real problems but scoped enough that it wasn't completely insane to try. I got a terminal backend working, a gap buffer, basic key handling and mode switching, some rudimentary rendering, and then ran into Windows terminal compatibility issues that I didn't really want to wrestle with in Zig specifically, and also at some point I noticed the project was starting to feel more like a vehicle for learning Zig than like actually building the thing I wanted to build, so I scrapped it and started over in Rust. The Rust version had basically the same structure as the Zig version: a Key type, a Mode enum, a gap buffer, some rendering, which meant it came together quickly since I'd already worked through most of the problems once, and by December 31st, ten days after the first commit, I had treesitter in.
I don't really like syntax highlighting, I think it makes you a worse programmer over time to need the colors to read the code, because it means the colors are doing cognitive work that your eyes and brain should be doing on their own, and I feel much the same way about LSP and things like inline type hints, unfortunately all of it is really awfully convenient in a way I find annoying, because I think it papers over a kind of understanding you should be building from the code itself, but I always end up turning it all on anyway because it's so frustratingly useful that forgoing it starts to feel like an unnecessarily principled stand I'm making at my own expense. I put treesitter in early because other people couldn't stand looking at code with me. If you've ever tried to share a screen or pair program in an editor with no syntax highlighting you know exactly the look you get the moment you open a file, and I was getting that look a lot.
The first several months were fast and messy in the way early projects are when you're learning what you actually want as you go and don't really have a spec beyond "an editor that works the way I think about things." I replaced the gap buffer with a rope on a piece table at some point because the gap buffer was making other things harder in ways I kept running into, and the rope has been fine since. I also wrote the regex engine from scratch, it's called monster-regex and it's a separate crate, the reasons were partly that I wanted to understand how search worked all the way down, which is just a thing I find interesting and worthwhile even when it's impractical, and partly that I had specific behavior in mind that no existing engine would give me cleanly. The search format is pattern/flags, where flags are single characters appended after the slash rather than passed as a separate argument, so /foo\ze bar/i matches "foo" in "foo bar" with the match end set just before the space, \zs and \ze are vim-style match boundary markers...