moe: a Vim inspired editor written in Nim, with a pluggable buffer

A Vim shaped editor in a systems language

moe is a command line based editor inspired by Vim, written in Nim, and the project states its goals as four adjectives: easily customizable, high productivity, user friendly, and high performance.

The choice of language is the first thing that tells you about the intentions. Nim compiles to C, produces a single native binary, and has a syntax that reads like Python, so an editor written in it can be both fast and readable, and the kind of project that is interested in a low level buffer representation is usually the kind of project that cares about what the compiler emits.

The feature list makes the Vim inspiration concrete rather than decorative. There are Vim like modes, covering Normal, Insert, Visual, Replace, Command, and a Filer mode, and there are Vim like keybinds, and a Vim like register. The tabs and the indentation lines follow the same pattern, and the incremental search and the undo and redo behaviour are the ones a Vim user would expect.

Around that core there is the set of conveniences that separate a text editor from a Vim-like editor. A TOML configuration file, a configuration mode with a user interface, a tab line, highlighting of the current word, highlighting and deleting of trailing spaces, automatic closing and deleting of parentheses, simple automatic indentation, incremental search, automatic saving, suggestions in command mode, TrueColor support, VSCode themes, building on save, a QuickRun action, automatic backups, Git support, bookmarks, a syntax checker, EditorConfig support, and macros.

The project is GPL-3.0 licensed, the default branch is develop, the site is editor.moe, and the last push was on 2026-10-20. The release history shows a long gap and then a burst, with v0.2.8.0 in July 2021, v0.3.0 in December 2021, and v0.4.0 in February 2026.

The name is a recursive acronym, moe is an optimal editor, and it also comes from the Japanese slang for the cute and moe aesthetic.

The buffer backend is the interesting part

From version 0.5.0 the buffer backend is selectable, and the documentation lists four implementations.

The gap buffer is the classic choice, an array of characters with the gap moved to the insertion point so that inserting in the middle is cheap. The square root decomposition splits the text into pieces of about the square root of the length, which is the trade-off between a long piece that is expensive to move and many small pieces that are expensive to look through. The rope, implemented as a B-tree, keeps the text in a balanced tree of chunks. And the piece table stores the text as a list of references into an original buffer and an append only buffer, which is the structure that makes collaborative editing and undo cheap.

Choosing between them is the kind of decision most editors hide, and moe exposes it, which means the performance claim is testable rather than asserted. A file of a few megabytes behaves the same under all four. A file of a few gigabytes does not, and the interesting thing about a selectable backend is that the right answer depends on what is being edited.

It is worth reading that list against the planned features, because the plan includes supports huge file, and the buffer backend choice is the mechanism that would make it true.

The other feature list entries around it are less exotic. UTF-8 and other encodings support is marked as incomplete, which is an honest flag for an editor written in a language with its own string handling assumptions. A terminal is listed from 0.5.0, and the Language Server Protocol support is marked as work in progress, with a long list of capabilities underneath it: completion, diagnostics, signature help, inlay hints, hover, goto definition, find references, call hierarchy, document highlight, document link, code lens, document formatting, rename, semantic tokens, folding range, selection range, and document symbol.

Listing the capabilities is one thing and shipping them is another, and the work in progress marker covers the whole group, so treat it as a roadmap rather than a feature list.

Two frontends, two sets of documentation, two install paths

The install section is split by version, and that split is the most important thing for anyone trying the editor.

The project recommends Linux environments. The requirement is Nim 2.0.10 or higher, and on GNU/Linux there are three optional clipboard tools, xclip at version 0.13 or higher, xsel, and wl-clipboard, each marked as an option for the platform.

For version 0.4.0 and below, which is the Ncurses base, the requirement is Ncurses 6.1 or higher, and the install is a single command.

nimble install moe

For version 0.5.0 and above, which is the Celina base, the install takes the head of the development branch.

# Latest developmental state inside Github repository
nimble install moe@#head

The two commands install different things. The first gives the last published release, the 0.4 line on Ncurses, and the second gives the current development state, the 0.5 line on Celina, which is the version with the selectable buffer backend and the language server work.

The documentation is split to match. There is a set of documents for the Celina base on the develop branch, and a separate set for the Ncurses base on the 0.4.0 tag, and the links in the usage section point at one or the other depending on which line you installed. That is a sensible arrangement, and it is also a hint about the state of the project, since it means the two lines behave differently enough to need different manuals.

The practical advice is to pick the published release if you want something that works today, and to read the develop branch documents before choosing the head of the development branch, because the two document sets do not describe the same editor.

Embedding the engine without the terminal

There is an embedding mode, and the description is unusually precise about what it does and does not include.

You build non-terminal frontends with the moe.embedded define and import the frontend package. The embedded mode keeps the editor engine and the frontend neutral input API available on Windows, while disabling the clipboard integration that Moe owns by default. It also excludes the terminal state, the handler, the renderer, and the POSIX PTY backend from the build, and imports only the platform neutral value types from Celina rather than its POSIX terminal runtime.

The last sentence of that paragraph states the division of responsibility. The embedding frontend owns the native clipboard and the terminal user interface, and the terminal commands report that the mode is unavailable.

So this is not a plugin system, it is a library extraction. The editor core, which is the part that knows how to represent a buffer, how to run a normal mode command, and how to keep an undo history, is separated from the terminal front end, so that a different front end, a native one, a web one, or a test harness, can drive it.

That is the same direction the rest of the project is heading. The buffer backends, the platform neutral value types, and the protocol support all point at an editor that is more of an engine with a terminal attached than a terminal program with an engine inside.

The planned feature list has a plugin system on it, and a fuzzy search, snippets, a spell checker, and editing files over ssh. The embedding mode is the closest thing to a plugin system that exists today, and it works at a lower level, at the boundary between the engine and the front end.

The project around the editor

A few things in the repository are worth noting for anyone deciding whether to depend on the project.

The package definition is a Nimble file, the Nim package manager's equivalent, with a lock file beside it, so the dependency set is pinned in the same way a lock file pins it in the JavaScript and Rust worlds. The tests have their own directory, and the continuous integration has separate workflows for the build, the tests, and something labelled CFF, which is the citation file format, and there is a CITATION.cff at the root of the repository. A citation file in an editor project is unusual, and it tells you that the project is used in published work, which in turn tells you that the language server support and the buffer backends have an audience beyond hobby use.

The example directory shows the shape of a real configuration. There is a keybindings file, a main configuration file with the moerc name, and a themes directory, which means a configuration is a set of TOML files rather than a single one, and that the VSCode themes are a separate example of the same idea.

There is an editorconfig file in the repository root, which is the same convention the editor honours, so the project applies to itself the standard it supports.

The community channel is a Discord server, and the contributing section invites bug reports and feature requests rather than describing a process. The licence is the GNU General Public License version 3, which is worth noting for anyone considering embedding the engine in a product, since it is the copyleft licence rather than the permissive one that a library like a text editor component would usually carry.

The overall picture is a project with real engineering in it, a clear direction, and an unusual position for a terminal editor, which is enough to make it worth trying on a machine where you can build it.

Editorial conclusion

moe fits a Vim user who wants a fast, scriptable terminal editor written in a systems language and wants to choose the data structure behind the buffer for the workload in front of it. It does not fit a user who wants a stable, feature complete editor today, because the language server support is marked as work in progress and several of the features on the list are still on the planned list rather than shipped. Verify first which line you are installing, since the Ncurses line and the Celina line have different requirements and different documentation, that the Nim version on the machine meets the stated minimum, and that the buffer backend you pick suits the file sizes involved, because the whole point of the choice is performance and the answer changes with the workload.

Frequently asked questions

Official sources

1. fox0430/moe on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases