Orbiton is a terminal editor that refuses to be configured

The no-configuration principle is the product, not a limitation

Orbiton states its leading principles up front, and they read like a manifesto rather than a feature list. The first is minimal annoyance within the limits of VT100. The second is that the editor should not be configurable, to help users stay focused, with the exception of themes. The third is to facilitate rapid edit-format-compile-run cycles. A configuration-free editor is unusual enough that it is worth being precise about what it removes and what it keeps. There is no keybinding file to maintain, no plugin system to update, and no settings to reconcile between machines. What remains is a fixed set of key commands. The author's stated reason is personal and blunt: too much time spent configuring text editors, IDEs and plugins. That origin also explains the shape of the project, which the documentation says is mostly written in itself, apart from some NeoViM in the early beginning. The editor therefore carries its own editor inside it, a self-hosting property that is unusual outside the Vim and Emacs worlds.

The fixed feature list makes daily behaviour predictable

Because there is nothing to configure, the interesting question becomes what the editor does out of the box, and the answer is a long list of specific behaviours rather than a settings dialog. Read-only files are shown with all text in red by default. Cursor movement tries to maintain the X position when moving up and down across short and long lines. Copy and paste are progressive: pressing ctrl-c once copies one line, again copies a block of lines until a blank line, and again copies the current function, while ctrl-v pastes one line the first time and the rest the second. Pasting lines copied out of a diff into source code strips the leading plus sign and space characters, which is the kind of small courtesy that only appears in an editor built by someone who does it daily. Bracket matching is on ctrl-r, which also opens or closes a portal, and with a portal open you can copy lines across files. Search is ctrl-f, with the tab key standing in for return to move into replace mode, and unicode runes can be searched in the u+0000 form.

Build, format and jump-to-error turn it into a small IDE

The edit-format-compile-run cycle is where Orbiton goes beyond editing text. Code can be built with ctrl-space or ctrl-b, and formatted with ctrl-w, for a wide range of programming languages. The project description also lists jump-to-error among the features, alongside gdb, dlv and LSP support, so a developer can compile a file, read the compiler's complaint and jump straight to the offending line without leaving the terminal. Debugging is described in the screenshots section: entering debug mode from the ctrl-o menu and stepping through assembly instructions of a Rust program with ctrl-n. Two smaller conveniences fit the same pattern. When merge conflict markers are present, Orbiton jumps to the first marker on open and ctrl-n moves to the next one. And a Markdown table editor is available through ctrl-t when the cursor sits on a table. Language specific help stays modest. Typing iferr on a single line in a Go or Odin program and pressing return inserts a suitable if err != nil block, based on the koron/iferr tool, which is template expansion rather than analysis. The repository topics list gleam, odin, rust, zig and go, a fair indication of the languages in use, though the build and format keys are described as covering a wide range rather than a fixed set.

Installing o from source takes one Go command and a rename

The development version installs with Go 1.25 or later, and the command below fetches the module and moves the resulting binary to a short name. The rename matters because every example in the documentation uses o rather than orbiton, and you are told to adjust the mv flags and the path as needed.

    go install github.com/xyproto/orbiton/v2@latest && mv -i ~/go/bin/orbiton ~/go/bin/o

If you would rather not compile, the releases page has prebuilt archives. The documented example is for a Raspberry Pi running Linux, and it pins a specific version, 2.74.6, so treat it as a template rather than a live command:

    curl -sL 'https://github.com/xyproto/orbiton/releases/download/v2.74.6/orbiton-2.74.6-linux_armv7_static.tar.xz' | tar JxC /tmp && sudo install -Dm755 /tmp/orbiton-2.74.6-linux_armv7_static/o /usr/bin/o && sudo install -Dm644 /tmp/orbiton-2.74.6-linux_armv7_static/o.1.gz /usr/share/man/man1/o.1.gz

The man page is installed alongside the binary, which is not incidental. Orbiton can render man pages, so a system that keeps the o.1 file in the man directory gets both the editor and its own documentation installed in one step.

Wiring o into git and MANPAGER takes two environment changes

The first real use is usually a commit message, and the intended invocation is EDITOR=o git commit. To make that the default for every repository, set the core.editor configuration globally, and undo it later with the unset form:

    git config --global core.editor o

    git config --global --unset core.editor

The same pattern applies to man pages. Setting MANPAGER to o makes the pager a full screen editor instead of a scrolling viewer, which is a real change in behaviour for anyone used to less:

    export MANPAGER=o

The alternative given for that is the less invocation with its own flags, which is the safe fallback if the editor is uncomfortable for long pages:

    export MANPAGER='less -s -M +Gg'

These are shell exports rather than Orbiton settings, which is the point of the design. The editor has no preferences of its own, so all behaviour changes happen in the environment it inherits.

osudo, fstab formatting and a built-in image viewer widen the scope

Orbiton is not only an editor for source files, and the listed use cases stretch past a single file buffer. The project description mentions man pages, Markdown, config files, source code and an image viewer, and the documentation adds that the editor has a built-in log, an optional nano or pico mode, a visudo replacement called osudo, and built-in support for neatly formatting /etc/fstab files. That combination is what makes the author consider putting it on a live image for a Linux or BSD distribution: the tool is limited by VT100, is small and self-contained, and carries its own documentation. The visudo replacement in particular is a specific safety feature, since the point of visudo is to edit a privileged file through a controlled path. The image viewer and the Markdown export workflow, whether to HTML or PDF, point the same way. Orbiton treats the terminal as a general purpose interface rather than assuming a code editor is the only thing anyone needs.

The build system targets BSD and Linux first, and macOS gets its own paths

The Makefile in the repository shows how carefully the platform matrix is handled. PREFIX is set to /usr/local on Darwin and on BSD systems, and to /usr on MinGW, MSYS and Cygwin, so the binary lands in a sensible place on each. The build itself defaults to CGO_ENABLED=0 and to GOFLAGS with -mod=vendor -trimpath, which produces a static binary with no cgo dependency. Architecture detection is handled by grepping /etc/os-release for an Arch Linux ID, and on Arch the build switches to PIE and adds -Wl,-O2,--as-needed,-z,relro,-z,now linker flags. The Makefile also exposes a gui target, and the repository carries a gtk3 directory, matching the mention of a VTE GUI application that can run the o editor. The package is BSD-3-Clause licensed, and the project is not archived, with the last push on 2026-10-17 and recent releases 2.74.6 on 2026-10-09, 2.74.5 on 2026-09-24 and 2.74.4 on 2026-06-18.

Where Orbiton is the wrong choice

The fixed feature set is the whole product, and it is also the boundary. A developer who arrives from Vim or Emacs and expects remapping, plugins or a plugin marketplace will find no configuration surface at all, since the not configurable principle is stated as one of the leading principles and only themes are excepted. There is no command history file, no persistent undo tree across sessions and no project specific settings, so a codebase that needs a house style enforced by tooling is out of scope. The VT100 limit has a second consequence: the interface is line oriented and text only, so an editor that must show a large file, a wide diff or a graphical layout at once is the wrong choice even though the syntax highlighting is there. On the build side, compiling from source needs Go 1.25 or later, and installing a prebuilt binary means trusting an archive from the releases page, with the documentation offering no signature verification step, unlike a project that publishes signed checksums. No rollback procedure is described either, so a live image builder should pin a known version rather than track the newest one.

Editorial conclusion

Adopt Orbiton when you want a single self-contained binary for commit messages, quick edits and edit-format-compile cycles, and reject it when your daily work depends on a plugin ecosystem or on custom keybindings. Verify first that your shell can launch the o executable and that the Go 1.25 requirement is met if you build from source, then confirm the packaged build matches the release you read about, since the documented Raspberry Pi install pins version 2.74.6.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. xyproto/orbiton on GitHub