Version 0.6 of aretext has been released! Aretext is a minimalist, terminal-based text editor with vim-compatible key bindings. Here’s what’s new!
Markdown syntax highlighting Aretext now supports syntax highlighting of markdown! It looks like this:
The current implementation supports most of the CommonMark 0.30 spec, including:
Headings Links Emphasis and strong emphasis (bold and italic) Bulleted and numbered lists Code blocks The new markdown parser has been validated against the CommonMark 0.
A few weeks ago, I implemented syntax highlighting for markdown in aretext, the minimalist vim clone I’ve been building. Like most context-sensitive languages, markdown is difficult to parse. Although it handles only a subset of the CommonMark 0.30 spec,1 my implementation required 845 lines of Go code.
Parsing is especially tricky because the code needs to handle any document a user might open. It can’t crash or enter an infinite loop.
Vim was my preferred text editor for nearly eighteen years, until I switched to aretext in 2021. I appreciated vim’s efficiency and ubiquity, the way I could rely on it regardless of what project I was working on or what machine I had ssh’d into. Like any software, however, vim reflects the time in which it was written. In many cases, vim optimizes for speed above all else, an approach that made sense given the limitations of late ’90s computers.
Today marks the fifth release of aretext, the minimalist text editor with vim-compatible key bindings! This post describes the highlights.
(Wait, what’s that? You say you want to install it right now? Well, then just go straight to the installation docs!)
Faster fuzzy menu search Aretext uses a trie-based fuzzy find algorithm for selecting files in a menu. This worked well for most projects… until I ran it after building Kubernetes.
On Sunday, I presented a lightning talk at the FOSDEM 2022 conference. Usually, FOSDEM takes place in Brussels, but recently it’s moved online. That was fortunate for me, because otherwise I probably would never have submitted a talk proposal!
The talk was about aretext, the vim clone I’ve been working on for the last couple years:
Pre-recorded talk: it’s just under 12 minutes long, and it doesn’t include the live Q&A session.
No one types perfectly. To compensate, many programs use “fuzzy find” algorithms to retrieve records close to what a user typed. Accidentally typed “quck” or “quack” when you meant “quick”? No worries! Fuzzy find will retrieve what you meant anyway.
This post explains the fuzzy find algorithm used in aretext, the terminal-based text editor I’ve been working on.
Design Goals In a typical editing session, the user will search for commands to execute or files to open.
I tend to rewrite code. A lot. The terminal-based text editor I’ve been building, aretext, started as a Rust project, but after a month I rewrote it in Go. At one point, the editor embedded a Python REPL, which I later ripped out and replaced with a searchable menu. I completely rewrote the input interpreter, syntax highlighting parser, word movement calculations, and fuzzy find algorithm – multiple times!
Last night, it occurred to me that I might have rewritten all the code in aretext at least once by now.
For the past nine months, I have spent almost all of my free time working on a coding side project. This is surprisingly common behavior for software developers. Some of us spend the entire work week coding for a company, then choose to continue coding as a hobby in our mornings, evenings, and weekends. I plan my work around my two-and-a-half-year-old daughter’s sleep schedule.
At the beginning of the project, I often imagined a voice asking nervous “why” questions.