# flow-control: eight months of commits after the last tag, and a config path called magical

> Flow Control is a Zig text editor distributed as one statically linked binary with tree-sitter parsers compiled inside it. Its README is unusually complete about building and unusually vague about where files go on macOS, and the three tagged releases in February 2026 have not been followed by a fourth despite commits landing two days ago.

**neurocyte/flow** — Flow Control: a programmer's text editor

- Repository: https://github.com/neurocyte/flow
- Website: https://flow-control.dev
- Stars: 2,456 · Forks: 121
- Language: Zig
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/neurocyte-flow

## Three tags in three days in February, then eight months of untagged commits

The release list is short and dated. v0.7.0 went out on 2026-02-12, v0.7.1 on 2026-02-14 at 16:06 and v0.7.2 on the same day at 16:37, so the three of them were cut inside a three day window and two of them inside half an hour. After that the tag stream stops, while the branch does not: the last push is dated 2026-10-02, two days before this snapshot. Eight months of commits with no fourth tag means the version you install from a package repository and the version in the working tree are not the same code, and there is no release note telling you what changed between them. The file itself calls the editor under active development and very stable and a daily driver for almost everything, which is three claims sitting next to a tag list that stopped in February.

## Infinite undo is a feature and persistent undo is on the work-in-progress list

The feature list advertises infinite undo, hedged with the phrase at least until you run out of ram, and the In Development list three sections down names persistent undo/redo. Both are about the same subsystem, and both are true at once: the history is unbounded inside a session and it does not survive one. The same pattern runs next to it. Language Server Protocol support is described as pre configured for most language servers in the feature list, while LSP completion support appears under In Development, so a reader cannot tell from the file which part of the protocol works today and which part is still being written. File watcher integration is third on that list, which means the editor does not currently notice that a file changed underneath it.

## On Windows the config path and the state path are the same string

Configuration lives under the standard user configuration path, and state lives under the standard user application state directory. On Linux those are two different places, `~/.config/flow` and `~/.local/state/flow`. On Windows the file gives `%APPDATA%\Roaming\flow` for both, so configuration, logs, traces and the per-project recently used file lists share one directory. Nothing says whether that is deliberate, and the file offers no way to move them apart. The macOS entry is the odd one out again: it is given as somewhere magical on MacOS, which is the one platform where the file declines to name a path at all. Logs and traces are grouped with the recent file lists under state, so on a Linux box they sit apart from your settings, and on a Windows box they sit in the same folder.

## Keybinding edits inherit from the built-in mode and only apply on restart

F4 switches the current keybinding mode, and the modes are named in the feature list: Flow Control for GUI IDE style bindings similar to vscode, plus Emacs, Vim, Helix and user created. Customising one is done with the `Edit keybindings` command, which opens a file in your `keys` directory under the same name as the mode, inheriting from the built-in one, so individual bindings can be added or overridden rather than replaced wholesale. Two details are easy to miss. Keybinding changes take effect on restart, so an edit is not live. And the sentence claiming that bindings added by future updates are inherited automatically is written as Keybindings added by future updates ar inherited automatically, with the e missing from are.

## zig build targets your own CPU unless you ask for the baseline

The build step is one line, and the file names the toolchain version it expects:

```shell
zig build -Doptimize=ReleaseSafe
```

Zig compiles for the specific CPU of the machine doing the building by default, and the file names the symptom of forgetting: illegal instruction errors, fixed by adding `-Dcpu=baseline` for generic CPU support. The cross-compile path is three more lines, for windows, for macos and for aarch64 linux musl, each with its own `--prefix` under `zig-out/`, and when cross-compiling the binary gets generic CPU support automatically. The result is `zig-out/bin/flow`, statically built by default, with every tree-sitter parser and query it needs compiled inside, which is why the file can say no additional runtime files are required and why copying one file to another machine is the whole install.

## The installer script is described in a sentence and shown nowhere

There is an installation guide on the project's website with instructions for using the installer script, and a downloads page listing source tarballs plus release and nightly binary builds. The command itself is not in the file. The same section closes by suggesting a local system package repository, and the file links a Repology page listing versions across distributions. The root of the repository carries a `contrib/` directory and a `build.zig.zon` alongside `build.zig`, so packaging material exists, but the file never says which distributions the contrib directory targets. There is also no `.github/` entry in the tree, so whatever release automation publishes the nightly builds is not configured by a workflow in this repository.

## The terminal section names kitty_mod for Kitty and stops there

The requirements are specific and worth reading literally: a modern terminal with 24bit color, ideally with the kitty keyboard protocol, a NerdFont supplied either by terminal font fallback or by a patched font, and a UTF-8 locale. Kitty, Foot and Ghostty are named as the recommended terminals and Zellij is said to work well, with most others expected to work with reduced functionality. The terminal configuration section then makes a recommendation, because Kitty, Ghostty and most other terminals bind keys that collide with normal editor commands. It names `kitty_mod` as the usual thing to rebind for Kitty, and the section ends on that clause. No equivalent advice for Foot, Ghostty or Zellij appears in the file.

## The manual ships in the repository and the second guide is labelled AI generated

Help is built into the binary and opens with F1 through the `Open help` command, and the same manual is on the website. A `help.md` file sits at the root of the tree next to `build.zig`, `src/` and `test/`, which is where a manual that ships inside the binary would live. The documentation section then points at the website for developer resources and at a DeepWiki guide for the same, labelling it AI generated and warning that accuracy may vary and details should be checked against the referenced source code. The sentence introducing the website resources is broken: can be found on the Flow Control website at, ending on the word at with no destination. Elsewhere the file writes Files to load may be specifed, missing the i.

## Conclusion

Take Flow Control if you want an editor that is a single file you can copy to a machine and run, and if your terminal reports 24bit color and can be nudged out of its own keybindings. Check two things before you commit to it. First, your macOS config path, which this file declines to state, and the fact that on Windows the configuration and the state directory are the same string. Second, what you expect from undo: the history is called infinite but persistence across restarts is still listed as work in progress. And if you build it yourself, add `-Dcpu=baseline` unless you want a binary tied to the CPU you built on.

## FAQ

### What is Flow Control and what is it written in?

It is a programmer's text editor written in Zig, published as a single statically linked binary named `flow` that contains its tree-sitter parsers and queries, so no extra runtime files are needed. The project page is flow-control.dev and the licence is MIT.

### How do you build Flow Control from source?

It builds with zig 0.16 using `zig build -Doptimize=ReleaseSafe`, and the binary lands at `zig-out/bin/flow`. Zig builds for your own CPU by default, so add `-Dcpu=baseline` if you hit illegal instruction errors or want a portable binary.

### What terminal does Flow Control need?

A modern terminal with 24bit color and, ideally, kitty keyboard protocol support. Kitty, Foot and Ghostty are the recommended ones and Zellij is said to work well. A NerdFont and a UTF-8 locale are also required.

### Does Flow Control have a plugin system?

Not yet. A plugin system is listed under Future, alongside collaborative editing and multi-terminal sessions. The In Development list holds LSP completion support, persistent undo/redo and file watcher integration.

### How do I open several files at once in Flow Control?

Pass them on the command line, as in `flow fileA.zig fileB.zig`. The last file is opened and the earlier ones are placed in reverse order at the top of the recent files list, which you switch to with Ctrl-e.

## Sources

- [License: MIT](https://github.com/neurocyte/flow/blob/master/LICENSE)
- [neurocyte/flow on GitHub](https://github.com/neurocyte/flow)
- [Project website](https://flow-control.dev)
- [README](https://github.com/neurocyte/flow/blob/master/README.md)
- [Releases](https://github.com/neurocyte/flow/releases)

---

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