# ad combines vi style keys with an Acme style file system interface

> ad is a Rust terminal text editor that mixes vim and kakoune modal editing with the extensibility model of Plan 9's Acme, where the text itself is executable and external programs can drive the editor through a virtual filesystem. The author calls it a playground and warns against using it as a daily driver.

**sminez/ad** — an adaptable text editor

- Repository: https://github.com/sminez/ad
- Website: https://crates.io/crates/ad-editor
- Stars: 745 · Forks: 30
- Language: Rust
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/sminez-ad

## An editor that is also a program environment

ad, pronounced A.D., is an attempt at combining a modal editing interface of the likes of vi and kakoune with the approach to extensibility of Plan 9's Acme. Inside ad, text is something you can execute as well as edit.

That last clause is the whole idea, and it explains the rest of the design. An Acme style editor is not a program with an extension API bolted on. The editor exposes its own state as a filesystem, external programs connect to that filesystem and read and write the buffers, and text inside a buffer can be bound to run as a command. The editor and the tools around it become a single environment rather than a host and a set of plugins.

The project carries an explicit warning. In the spirit of Plan 9 itself, ad is primarily intended as a playground for experimenting with implementing various text editor features, and it is currently not recommended for use as a primary text editor.

The status section repeats the point with more detail. ad is now stable enough to try out, but there is very little documentation and there are likely to be a variety of bugs and crashes in places the author has not fully tracked down. For now there is not a whole lot of user facing documentation other than the built in :help section, so you will need to read through the source code and GitHub issues to learn about what is and is not implemented.

## Building it and installing the dotfiles

Packaging of the project, including the default config files and helper scripts, is not currently in place, so the recommended way to try ad is to clone the repository and compile from source.

```bash
$ git clone git@github.com:sminez/ad.git
$ cd ad
$ cargo install --path .
$ cargo xtask setup-dotfiles
```

The third command is the one to look at before running it. The README points to the setup.rs file for the actions carried out by the setup-dotfiles task and says you should review them and make sure you are happy to proceed before running it, which is a reasonable thing to ask of a task that writes configuration into your home directory.

After that you open ad and run the :help command to view the built-in help. There is also a video tour linked from the README, with a caveat that given the early stage of the project and frequent changes to the codebase, the exact content of the video tour may not accurately reflect the current state of ad.

That caveat is worth taking seriously, because the project status section says the same thing about the editor itself: it is under active development, and while the author aims to avoid arbitrary incompatible changes to the way the editor works, he is not yet fully committing to stable keybindings or default behaviours. If something stops working after an update, the advice is to read the git log.

## The internals are the interesting part

The design section lists what ad is trying to be, and it reads as a list of borrowings rather than a manifesto. There is vim style modal editing, convenient text navigation and selection from vim and kakoune, mini-buffer based user defined minor modes from emacs, sam and acme style editing commands for larger editing actions, and acme style extension through exposing editor state and functionality for external client programs.

Mouse support is there but deliberately not the main way of using the editor, since that is fine on a desktop but most of the time the author is on a laptop, where it is far too clunky.

The stated ambition is worth quoting, because it explains the whole architecture. ad is not trying to replace vim, kakoune or emacs in terms of being a massively hackable editor. It is trying to follow the philosophy of acme in being an integrating development environment rather than an integrated one. The aim is to provide a comfortable editing environment that supports direct interaction with external tools and programs from the outside rather than pulling everything in.

The modules list in the README is the concrete version of that. There is a gap buffer implementation for the internal state of a buffer, a dot module for manipulating the current selection including vim-like motions, an exec module with a minimal implementation of the core of the sam editing language, a virtual filesystem interface to the editor state in the style of acme, a minimal LSP client, a 9p protocol implementation backing the filesystem module, a custom regex engine that works on character streams, tree-sitter based syntax highlighting with optional per-line regex highlighting when grammars are unavailable, and a trie data structure for sequence based keybindings.

Two of those have since moved into their own crates. The exec engine is now structex, and the 9p implementation is now the ninep crate, both with their own repositories.

## A custom regex engine and a custom exec language

The two decisions that separate ad from a normal editor are the custom regex engine and the exec language, and the README is honest about the trade-off in the regex case.

The regex module is a custom engine able to work on character streams. It is nowhere near as performant as the regex crate, obviously, but it allows for some flexibility in tinkering with the exec command language.

That sentence is the key to reading the whole design. The regex engine does not exist to be fast. It exists because a regex that operates on a stream of characters can be evaluated in a way that a compiled regex cannot, and that is what the exec language needs. The exec module is a minimal implementation of the core of the sam editing language, and a blog post on the author's site, titled around matching sam again, gives an overview of how the system works.

The LSP client is described as minimal, and the syntax highlighting uses tree-sitter with a fallback: optional per-line regex based highlighting if grammars are unavailable for a particular filetype. That fallback is a pragmatic choice for a text editor that has to open whatever file you point it at, including files it has never heard of.

The keybinding system uses a trie for sequence based keybindings, which is the standard approach for modal editors and explains why multi-key sequences do not slow down dispatch the way a linear lookup would.

## Building on the filesystem interface

The README points at the data/bin directory of the repository for examples of what the filesystem interface makes possible, and links a Zettelkasten note taking application built by davcam as a concrete example.

The architecture section says the same thing in one line. The fsys module is a virtual filesystem interface to the editor state in the style of acme, and the ninep module is the 9p protocol implementation that backs it.

This is the part that has no equivalent in a vim or emacs workflow, and it is why the editor is a laboratory for editor design rather than a competitor. The filesystem is the API. An external program talks to the editor the way a program talks to a Plan 9 filesystem, and the 9p protocol is what makes that possible across process boundaries.

It also explains the project topics. Alongside rust, text-editor, tui and regex, the repository is tagged 9p, acme and plan9, which is a much more accurate description of what the project is than the word editor.

The repository layout backs this up. There is a crates directory that the workspace members glob picks up, an xtask directory for the build automation, a fuzz directory with a fuzz feature behind the arbitrary dependency, reference-tests, a tree-sitter-plumbing-rules directory, benches, a build.rs and a justfile that drives the checks.

## The contributor rules are unusually strict

The contributing section sets expectations before you write a line of code, and it is worth reading before you plan a patch.

The project as a whole is not particularly well suited for external contributors in its current state, so the request is to raise an issue to discuss any proposed changes or feature requests first rather than directly opening pull requests. Outside of minor bug fixes and typo corrections, the author says he is unlikely to be able to do anything other than close pull requests that were opened without prior discussion of the issue they intended to address.

The rest of the tooling matches that. The justfile installs cargo-nextest and typos-cli, runs the workspace tests through nextest, and runs criterion benchmarks with a report opened in firefox. There are check targets for formatting with cargo fmt, clippy across the workspace with all targets and features and warnings denied, rustdoc with warnings denied, and spelling with typos, and a check-all target that runs the spelling, format, clippy and docs checks together. There is also a todo recipe that greps for TODO and FIXME markers in src and crates.

A fuzz recipe runs cargo fuzz against a target, with a default of input_handling, a five minute cap, and four workers, and a watch-tests recipe that uses entr to rerun the nextest suite whenever a git tracked file changes.

## Conclusion

ad suits a developer who wants to understand Acme style editors and is willing to read the source, since the 9p backed virtual filesystem and the sam derived exec language are the interesting parts rather than the keybindings. It is the wrong tool for daily work, because the author states plainly that it is not recommended as your primary text editor, that keybindings and default behaviours are not yet stable, and that documentation is thin beyond the built in help. Before trying it, clone and build from source as the README describes, read what the setup-dotfiles task will do, and expect to consult the git log after each update.

## FAQ

### How do I build and try out the ad text editor?

Clone the repository, run cargo install --path . and then cargo xtask setup-dotfiles, which the README says you should review before running because it writes configuration. Then open ad and run the :help command for the built in help.

### Is ad suitable as a daily driver text editor?

No, not according to its own author. The README says ad is primarily intended as a playground for experimenting with text editor features and is currently not recommended for use as a primary text editor, and the project status section warns that keybindings and default behaviours are not yet committed to being stable.

### What makes ad different from a vim or emacs style editor?

It follows the philosophy of Acme in being an integrating development environment rather than an integrated one, exposing editor state through a virtual filesystem interface backed by a 9p protocol implementation, so external programs drive the editor from the outside rather than being pulled in as plugins.

## Sources

- [License: MIT](https://github.com/sminez/ad/blob/develop/LICENSE)
- [Project website](https://crates.io/crates/ad-editor)
- [README](https://github.com/sminez/ad/blob/develop/README.md)
- [Releases](https://github.com/sminez/ad/releases)
- [sminez/ad on GitHub](https://github.com/sminez/ad)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sminez-ad