curlpipe/ox: a Rust terminal editor built around Lua configuration and plugins

What Ox solves, and who it is actually for

Most terminal editors ask you to accept a model of editing before you can change anything else. Vim expects modal commands, nano expects a fixed set of control-key shortcuts, and micro sits somewhere between the two with its own key map. Ox takes a different position: the README describes it as "a text editor that can be used to write everything from text to code" and lists configurability first among its selling points. Colours, key bindings and behaviours are all meant to be changed, and the configuration language is Lua rather than a bespoke file format.

The intended user is an engineer who already lives in a terminal and has opinions about how an editor should behave. Ox is not modal, so the README's quick start tells you to type letters and numbers immediately after launch, delete with backspace, indent with tab and break lines with enter. That removes the largest source of friction for people coming from GUI editors. The second audience is plugin authors: the repository ships a plugins/ directory and the README points to a library of community plugins covering Discord RPC, git integration, Emmet and an HTML viewer, a Pomodoro timer and todo tracker, and AI code suggestions.

Ox is built from the ground up rather than forked from an existing editor, which the README states explicitly. That matters for adoption: there is no upstream to inherit fixes from, and no compatibility layer for Vim or Emacs configuration. Everything you get is what the project itself implements.

How Ox is put together: Rust, crossterm and a Lua runtime

The Cargo.toml shows a small, legible dependency set. crossterm 0.28.1 handles terminal input and output, which is how Ox draws its tab line, status line and feedback line and how it receives mouse events for cursor movement and text selection. mlua 0.10 is built with the lua54 and vendored features, so a Lua 5.4 interpreter is compiled into the binary rather than linked from the system. That is why Lua is the configuration language: the editor does not need an external interpreter present at runtime.

The workspace has two members. The main ox package holds the editor, and kaolinite is a path dependency included in the same repository. The package metadata also lists alinio, jargon-args for command line parsing, error_set, shellexpand, synoptic for syntax highlighting, regex, and base64. On non-Windows targets there is a second dependency group containing ptyprocess, mio and nix, which is what makes the README's claim of terminals inside the editor plausible: a pseudo-terminal has to be spawned and polled, and those three crates are the pieces for doing that on Unix-like systems.

The release profile in Cargo.toml is commented out, including lto, panic abort and codegen-units. That is worth noting for anyone building from source: the default release settings apply, so build times and binary size are whatever Cargo produces without those tweaks. The package include list is narrow (src/*.rs, Cargo.toml and config/.oxrc), so the published crate carries the configuration file alongside the source.

Installing Ox and finishing the set-up wizard

The README treats the manual build as the best route because it tracks the latest version and matches your system. You need a working Rust toolchain from rustup first, then a single cargo command. The README says this takes around two minutes on slower machines and around 30 seconds on more modern ones.

cargo install --git https://github.com/curlpipe/ox

The binary lands in .cargo/bin, which the README notes should be on your path and says rustup will usually handle. If you prefer a packaged install, the README lists ox-bin and ox-git on the Arch AUR, an RPM on the releases page installed with sudo dnf install /path/to/rpm/file, a deb installed with sudo dpkg -i /path/to/deb/file, and on macOS both brew install ox and sudo port install ox. Precompiled binaries for all three platforms are on the releases page; on Linux the README suggests copying the ox executable to /usr/bin/ox and running sudo chmod +x /usr/bin/ox.

Once installed, launch it with no arguments:

ox

The first run matters. If no configuration file exists, the README states that Ox walks you through a set-up wizard, and after completing it you land in an empty unnamed document. The layout is three horizontal bands: tabs at the top, editor state at the bottom, and a feedback line at the very bottom for information, warnings and errors. Press Ctrl+H to toggle the built-in help message, which the README presents as the introduction to most key bindings. Press it again to hide it.

Editing features that come from the editor, not from plugins

The out-of-the-box list is longer than the plugin list, which is a useful signal about where the project put its effort. Syntax highlighting, undo and redo, search and replace, opening multiple files at once, mouse-driven cursor placement and selection, and splits for viewing several documents on one screen are all built in. So are multiple cursors and recordable macros, a file tree that can view, open, create, delete, copy and move files, and access to terminals inside the editor.

The file tree is the feature that most changes daily use. In a plain terminal editor you usually drop to a shell to create or move a file, then reopen it. Ox folds that loop into the interface. Terminals inside the editor come from the Unix-only ptyprocess, mio and nix dependencies, so on Windows this particular capability is not part of the build; the README still lists Windows as supported, but the dependency split in Cargo.toml shows the terminal feature is Unix-side.

Multiple cursors and macros are the other pair worth calling out, because they are the features that separate a toy editor from one you can work in all day. The README lists them without describing the key bindings, and defers detail to the wiki. That is the pattern throughout: the README is a shop window, and the wiki is the manual.

Where Ox is the wrong tool

The README does not document rollback, and there is no mention of a trash or recovery mechanism for deleted files in the file tree. If you delete a file from that tree, the documentation gives no indication that Ox can bring it back. Treat the file tree as a real filesystem operation, not a staging area.

Configuration is Lua, and that is a genuine filter. If you want to change a colour or a key binding, you are editing a program, not filling in a form. The set-up wizard covers the first pass, but anything beyond it means reading the wiki's configuring section. Engineers who want a config file they can copy from a blog post will find the Lua layer heavier than they expected.

Plugin availability is the second limit. The README names Discord RPC, git integration, Emmet and an HTML viewer, a Pomodoro timer and todo tracker, and AI code suggestions. That is a short list compared with what long-lived editors accumulate, and Ox is not based on any existing editor, so plugins written for other tools will not load. If your workflow depends on a specific language server integration or a particular linting plugin, check the wiki's plugins section before you switch.

Finally, the release cadence is slow. The most recent release in the repository's history is 0.7.7 from 2025-03-13, and the last push to the default branch was on 2026-04-23. There is no archived flag, so the project is not formally retired, but the gap between releases and pushes means you should not expect rapid fixes to issues you file.

Ox against micro, and against modal editors

The nearest comparison is micro. Both are non-modal terminal editors with mouse support, both aim at people who do not want Vim's command grammar, and both ship syntax highlighting out of the box. The difference is in the extension and configuration layer. Micro is configured and extended in Lua as well, but it is a mature project with a long-standing plugin ecosystem and a broad set of language definitions. Ox's distinguishing choice is that it was written from scratch rather than built on an existing editor's core, and that its configuration, plugin system and set-up wizard are treated as first-class parts of the product rather than add-ons.

Against Vim or Neovim, the split is the editing model. Ox is not modal, so every keystroke is text until you press a control combination. That is faster to learn and slower to become fluent in, because modal editors trade an initial learning cost for a large vocabulary of composable commands. If you have already internalised Vim's grammar, Ox will feel like giving up an advantage. If you never got past the tutorial, Ox removes the reason you stopped.

Against nano, the difference is scope. Nano is a small editor with a fixed feature set and a visible shortcut bar; there is little to configure and little to break. Ox carries a Lua runtime, a plugin loader and a file tree, which is more surface area and more places for a bad configuration to change behaviour.

Licence position and the cost of staying current

Ox is licensed GPL-2.0, and the Cargo.toml declares license = "GPL-2.0". The RPM metadata generated from the package places the LICENSE file at /usr/share/doc/ox/LICENSE alongside the README. For individual use this is unremarkable. For anyone embedding Ox in a product, the copyleft terms of GPL-2.0 are the relevant consideration, and that is a question for your own legal review rather than something this article can settle. Note also that the Lua runtime is vendored through mlua with the lua54 feature, so the distributed binary contains Lua 5.4 compiled in; if you redistribute a build, the licence obligations of the components you ship apply.

Upgrade cost depends on your install method. The cargo install --git route pulls from the default branch, so an upgrade means re-running the same command and getting whatever is on master at that moment, with no release boundary in between. Package-managed installs (AUR, Homebrew, MacPorts, RPM, deb) move when the packager updates them, which may lag the repository. Because the most recent release is 0.7.7 from 2025-03-13, the gap between releases is wide enough that the git route and the packaged route can diverge substantially. If you depend on a specific behaviour, pin your install method to one of them and check the wiki's roadmap section, which the README lists as the sixth documentation stage, before upgrading.

Editorial conclusion

Adopt Ox if you already work in a terminal, want to write your own configuration and plugins in Lua, and are willing to read the wiki because the README stops at the first steps. Do not adopt it if you need a modal editing model, a large existing plugin ecosystem, or a project with commits in the last few months: the last push was on 2026-04-23, so treat it as a stable but slowly moving codebase. Before committing, install it with cargo install --git https://github.com/curlpipe/ox, run ox once to complete the set-up wizard, and confirm that your terminal reports mouse events and that the Ctrl+H help screen matches the keys you expect.

Frequently asked questions

Official sources

1. curlpipe/ox on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases