Flow Control: a Zig TUI text editor with tree-sitter and LSP built in

What Flow Control solves, and who it is actually for

The pitch is narrow and specific: a terminal editor that behaves like a GUI IDE out of the box. The README describes "zero configuration" for syntax highlighting across more than 70 programming languages, and says Language Server Protocol support is preconfigured for most language servers. That combination is the reason to look at it. Most TUI editors ask you to assemble highlighting, a language server client, and keybindings before the editor is useful. Flow Control ships those decisions already made, then lets you override them.

The intended user is a programmer who works inside a terminal and does not want to maintain a config tree. The README calls it "my daily driver for almost everything", which is a single-maintainer statement of confidence rather than a support commitment. If your work depends on an editor with a foundation behind it, that framing matters more than any feature list.

The keybinding modes are the second half of the pitch. Flow Control ships modes named Flow Control (described as GUI IDE style, similar to vscode), Emacs, Vim and Helix. Someone moving off Helix or Vim can keep muscle memory while getting the rest of the editor, and F4 switches modes at runtime.

The buffer, the parsers, and the single-binary design

Two mechanisms carry most of the architecture. The first is the buffer: the README describes a "hybrid rope/piece-table buffer system" intended to keep very large files editable with thousands of cursors. Rope and piece table are different answers to the same problem, and a hybrid is a deliberate compromise between edit locality and memory behaviour. The README does not publish measurements for either, so treat the claim as a design description, not a benchmark.

The second is the packaging model. Tree-sitter parsers and queries are compiled into the binary. The README states the output binary is statically built by default and "contains all the required tree-sitter parsers and queries. No additional runtime files are required." That is why installation can be a file copy. It also explains why the binary is large and why a language you care about exists only if it was compiled in.

Around that sit the visible features: tabs, scrollbars, palettes, full mouse support, multi-cursor editing, clipboard history, infinite undo bounded by RAM, and full unicode support including the kitty text sizing protocol. The README claims frame times of 6ms or less with animated scrolling. That figure comes from the project, and there is no independent measurement in the repository.

Installing Flow Control and opening your first file

The README points to an installation guide on the project site with instructions for an installer script, and to a downloads page with source tarballs plus release and nightly binaries. It also suggests checking your local package repository. If you build from source, the README says Flow builds with zig 0.16 at this time. Run the build from the repository root:

zig build -Doptimize=ReleaseSafe

The binary lands at zig-out/bin/flow. Zig builds for your specific CPU by default; the README says to add -Dcpu=baseline if you hit illegal instruction errors. To put it on your path, either copy it or let zig install it into your home directory:

zig build -Doptimize=ReleaseSafe --prefix ~/.local

Because the binary is statically linked, the README notes you can copy it to another machine directly, for example with scp into /usr/local/bin. Opening files is the same command with arguments. The last file listed is opened and the earlier ones go to the recent files list in reverse order, reachable with Ctrl-e:

flow fileA.zig fileB.zig

Line specifiers work in both common styles, so flow file.txt:123 and flow file.txt +123 both land on line 123. If detection gets a file wrong, force the language with --language, and list the accepted names with --list-languages:

flow --language bash ~/.bash_profile

Once inside, F1 opens the built-in manual, F4 switches keybinding mode, and ctrl+shift+p or alt+x opens the command palette. ctrl+F2 lists every current keybinding and command. Configuration lives under the standard user configuration path, usually ~/.config/flow on Linux, and the README says to reach it through commands starting with Edit in the palette rather than by finding files by hand. Keybinding changes take effect on restart.

Where Flow Control falls short, and when to pick something else

The roadmap is the clearest statement of what is missing. LSP completion support, persistent undo/redo, and file watcher integration are listed as in development, not shipped. So the language server integration gives you diagnostics and navigation, but not completion. Undo works, but it does not survive a restart. If a file changes on disk underneath you, nothing watches it.

Further out, the README lists collaborative editing, a plugin system, and multi-terminal sessions as future work. The absence of a plugin system is the structural limitation: anything the editor does not already do has to come from the maintainer or a patch. Compare that with an editor whose extension ecosystem covers the gap.

The terminal requirements are a real constraint, not a footnote. A modern terminal with 24bit color is required, and the kitty keyboard protocol is described as ideal. Kitty, Foot and Ghostty are the recommended terminals, and Zellij is called out as working well. The README says most other terminals will work "but likely with reduced functionality", without enumerating what degrades. NerdFont support is also required, through fallback or a patched font, and a UTF-8 locale is mandatory.

Platform support is broad on paper: Linux, FreeBSD, MacOS, Windows and Android under termux, with cross-compilation to all supported targets. The README does not describe platform-specific behavioural differences, so if you work on Windows, verify the terminal side yourself rather than assuming parity.

How Flow Control differs from Helix and Neovim

Helix is the closest comparison, and the difference is in defaults and distribution. Helix is a modal editor built around a selection-first model, and its tree-sitter and LSP integration is assembled from configuration and external binaries on your system. Flow Control compiles parsers and queries into one static binary and preconfigures language servers, so there is no per-language setup step. Helix gives you a mature modal editing model as the primary interface; Flow Control treats modal editing as one of several switchable modes, with a GUI IDE style mode as the default.

Neovim differs on the axis that matters most here: extensibility. Its plugin ecosystem is the reason people accept the configuration burden. Flow Control has no plugin system yet, so the trade is inverted. You give up extensibility and gain a binary you can copy between machines.

One practical wrinkle: the README lists Helix as a built-in keybinding mode. If you are leaving Helix because you want less configuration rather than different bindings, Flow Control lets you keep the bindings and change the packaging. That is a narrower reason to switch than it first appears.

Maintenance, licence, and what an upgrade costs you

The repository is not archived, and the last push was on 2026-09-26. Releases are frequent enough to track: v0.7.0 on 2026-02-12, then v0.7.1 and v0.7.2 both on 2026-02-14. The README describes the project as under active development and notes that the maintainer uses it daily, which is a reasonable signal for a tool of this size but not a guarantee of response times on issues.

Upgrade cost is unusually low for a TUI editor, and the single-binary design is why. Replacing the binary replaces the parsers and queries with it. Your configuration under ~/.config/flow and your state under ~/.local/state/flow sit outside the binary, so they survive the swap. Logs, traces and per-project most recently used file lists live in the state directory, which is worth knowing before you clear it.

Keybindings are the one upgrade path with a documented behaviour: the README says the file opened by the Edit keybindings command inherits from the built-in mode, so keybindings added by future updates are inherited automatically. That means an upgrade can change keys you never overrode. Changes take effect on restart, so test after upgrading rather than mid-session.

The licence is MIT, which permits use, modification and redistribution provided the copyright notice and permission notice are preserved. That is a permissive licence with no copyleft obligation, but read the LICENSE file in the repository for the exact terms rather than relying on the identifier.

Editorial conclusion

Adopt Flow Control if you already live in Kitty, Foot, Ghostty or Zellij and want a single static binary with LSP wiring you did not have to write. Do not adopt it if you need in-buffer completion, persistent undo, a plugin API, or collaborative editing, since the README lists all four as roadmap items rather than shipped features. Before committing, check two things yourself: that your terminal handles 24bit color and ideally the kitty keyboard protocol, and that a NerdFont is available through fallback or a patched font. Then run flow --list-languages against the file types you actually edit, because a language appearing in that list is what decides whether tree-sitter highlighting and the preconfigured language server apply to your work.

Frequently asked questions

Official sources

1. License: MIT
2. neurocyte/flow on GitHub
3. Project website
4. README
5. Releases