f4 — efficient and cozy file manager in go

⚡ Quick Download (Nightly Builds)

Platform	Format	Link
Windows	.zip	amd64 / arm64
Windows 7/8/8.1	.zip	amd64
ReactOS (details)	.zip	x86
macOS	.tar.gz	amd64 / arm64
Android (Termux)	.tar.gz / .deb	arm64 archive / arm64 package / armv7 archive / armv7 package
Linux	.tar.gz	amd64 / arm64 / armv7l / 386 / mips / mipsle / mips64 / mips64le / riscv64 / loong64 / ppc64 / ppc64le
FreeBSD	.tar.gz	amd64 / arm64
DragonflyBSD	.tar.gz	amd64
OpenBSD	.tar.gz	amd64 / arm64
NetBSD	.tar.gz	amd64 / arm64
Illumos (experimental)	.tar.gz	amd64
Solaris (experimental)	.tar.gz	amd64
Linux (lite) (details)	.tar.gz	amd64 / armv7l / mipsle
Windows (lite) (details)	.tar.gz	x64
Experimental ports	—	Redox, GNU Hurd, Haiku

These builds are automated and represent the current state of the main branch.

An installed f4 updates itself from the command line, no browser needed:

f4 --update nightly   # newest nightly build
f4 --update stable    # newest tagged release
f4 --update           # whichever channel is configured (Options > Auto update)

A named channel also becomes the one f4 checks automatically from then on.

🍺 Install on macOS via Homebrew

Tagged releases (vX.Y.Z) are published to a Homebrew tap, so you can install with one command:

brew install unxed/tap/f4

To upgrade later: brew upgrade f4. Both Apple Silicon (arm64) and Intel (amd64) Macs are supported.

The tap carries tagged releases only, so a nightly build has to come from f4 itself: f4 --update nightly writes it into the Cellar directory brew installed to. That works, and brew upgrade or brew reinstall puts the tagged release back whenever you want it.

❄️ Install via Nix

The repository is a flake. Run f4 without installing it:

nix run github:unxed/f4

The default package contains both terminal and graphical modes. To start a graphical window explicitly, use nix run github:unxed/f4#gui. The separate f4-tty package is compiled without GUI backends and installs f4-tty; run it with nix run github:unxed/f4#tty. Both packages can be installed together. The flake exports them as packages.<system>.f4-gui and packages.<system>.f4-tty (and as pkgs.f4-gui and pkgs.f4-tty through the overlay). packages.<system>.f4 remains an alias of f4-gui.

For a persistent install, add overlays.default to your configuration and use pkgs.f4; nix develop github:unxed/f4 opens a Go development shell.

Home Manager

The flake also exports homeManagerModules.default, a module managing f4 as programs.f4:

{ inputs, ... }:
{
  imports = [ inputs.f4.homeManagerModules.default ];

  programs.f4 = {
    enable = true;
    settings = {
      Interface.ColorStyle = "Radiola";
      Panel.ShowHiddenFiles = false;
    };
  };
}

programs.f4.package defaults to pkgs.f4, so the overlay above (or an explicit package) is needed. Besides settings (settings.ini), the module declares keymap (keymap.ini), hotkeys (hotkeys.ini) and highlight (highlight.ini); each option's description documents the file's format.

f4 keeps settings and state in the same files and rewrites them at runtime, so Home Manager does not take those files over. Every home-manager switch writes the keys you declare into the live files and touches nothing else in them: values changed through f4's own UI revert to the declared ones on the next switch, and keys removed from the configuration stay in the files until deleted there by hand.

📱 Install on Android via Termux

The Android build targets Termux on arm64 and on 32-bit armv7 devices. Download the .deb package for your device above and install it from Termux (dpkg --print-architecture in Termux prints aarch64 or arm, which tells you which one you need):

pkg install ./f4-termux-arm64.deb   # arm64
pkg install ./f4-termux-arm.deb     # armv7

A pkg install f4 from Termux's own repository is not available yet: the recipe for it is packaging/termux/build.sh, waiting for a pull request to termux/termux-packages (#12).

Alternatively, extract the .tar.gz archive and run ./f4. Both artifacts are linked against Termux's libraries and are intended to run inside Termux; they are not standalone Android APKs. x86_64 (Chromebooks, emulators) is not published yet.

🪟 ReactOS

The ReactOS build is tested on ReactOS 0.4.16 (x86). Download f4-legacy-windows-386.zip, unpack it, and run f4-legacy.exe from a command prompt. f4-legacy.exe --gui win32 opens f4 in a window of its own instead of the console.

It is a 32-bit Windows build with its imports patched by go2xp: every Go release since 1.21 imports kernel32 functions that ReactOS, like any Windows before 10, does not have, and without the patch the loader refuses to start the program at all.

Both the console and the window mode work: panels, viewer, editor, file operations, archives and running commands. One limitation in the window mode: ReactOS has no working pseudo-console (ConPTY), so a command's output goes to a scrollable output window instead of a live terminal, and interactive console programs cannot be given input there — run those from the console mode.

Not tested on ReactOS: self-update (f4 --update). Not claimed for Windows XP: XP lacks a few functions ReactOS has.

🛜 Lite build

The lite build targets routers and other embedded/old-weak-hardware devices. Its GUI backends are the ones that draw with the display server's own protocol: X11 and Wayland (--gui=x11, --gui=wayland), Win32 GDI on Windows (--gui=win32), and the native Cocoa window on macOS (--gui=cocoa, also the automatic default there since a lite build has no gogpu) -- unlike the other three, Cocoa needs no separate display server, so it needs no XQuartz; the GPU-accelerated gogpu and ebiten backends, and the graphics stack behind them, are left out. Wayland needs a loader to reach libxkbcommon, so it is available on the amd64 build, which is universal like the regular one; the static arm and mipsle builds draw with X11. There is no Colorer (Chroma-based syntax highlighting only), no Wine-specific code or libwinescape dependency, no MP3 player, no FUSE-based VFS mounting, and no cloud VFS provider. Archives come back through plugins/multiarc, which wraps whichever of tar, unzip/zip, 7z/7za/7zr and gzip the host already has on PATH instead of linking the regular build's native archive libraries (f4#1178, part 2). Like far2l's multiarc it lists, extracts and, as far as each tool can do it safely, changes archives: copying onto an opened archive, F7 and F8 add, replace and delete members through 7z, zip (or 7z/7za) for zips, and GNU tar for tarballs (a compressed one via its stand-alone compressor); bsdtar (macOS, Windows' tar.exe) only adds members, BusyBox tar cannot change an existing tarball, and a lone .gz can only have its one file replaced. Add to archive (Shift+F1) creates a .zip, .7z, .tar or compressed tarball with whichever of those tools is present — bsdtar makes zips too. Whatever the tools on PATH cannot do is refused with a message saying what is missing. Network access comes back too, but only as FISH+: plugins/netfox keeps its connection storage and its "Add/Edit connection" dialog, wired to a dialer that shells out to the console ssh binary instead of linking golang.org/x/crypto/ssh — the same "wrap the console tool" story as multiarc — while pkg/sftp, jlaffaye/ftp and kbolino/pageant (and their own FTP/SFTP backends) stay out entirely (f4#1178, part 3). That subprocess dialer covers key- and ssh-agent-based auth; password auth, an explicit HTTP/SOCKS5 proxy and this build's own host-key handling are not supported (its own comment in plugins/netfox/fish_dialer_lite.go has the detail on why). The build links none of the archive libraries either: the updater and PlugRing unpack f4's own .tar.gz and .zip downloads with Go's standard library. The build links no SQLite engine (ncruces/go-sqlite3, about 7 MB): the SQLite client (Ctrl+Alt+D, and Enter on a database file) runs the host's sqlite3 command-line tool instead (opkg install sqlite3-cli, apt install sqlite3), one process per statement, so a transaction begun in its SQL box ends with that statement. The built-in spreadsheet (Ctrl+Alt+S) keeps working, but saves its native .f4s files as plain JSON instead of a SQLite database (f4#1552). The two on-disk formats are not interchangeable — see the "Files" section of docs/SPREADSHEET.md for the trade-off. Everything else — panels, editor, viewer, Lua and wasm plugins — works the same as the regular build. Built with go build -tags lite,vtui_noebiten,vtui_nogogpu; the two vtui tags drop its Ebitengine and gogpu backends, and a lite build without them does not compile. See internal/plughost, internal/gui, internal/editor, vfs/hostmode, internal/media, internal/fusefs and internal/sheet for where each exclusion is implemented.

An extra-lite profile (-tags lite,extralite,vtui_noebiten,vtui_nogogpu) goes further for routers: only English and Russian embedded, only the built-in plugins that mc has an equivalent of, no Lua and no WASM runtime, no collation tables. It is built for OpenWrt (.ipk packages, see the openwrt workflow); the target matrix, sizes and what is left out are in docs/OPENWRT.md.

The Core: Creating an experimental, cross-platform TUI (Terminal User Interface) file manager that aims to fully replicate the features, UX, data structures, and rendering logic of far2l and Far Manager, but implemented entirely in Go.

🧪 Experimental: Redox, GNU Hurd, Haiku

Ports to three more OSes are in progress in unxed/sandbox, built and verified only in that repo's own GitHub Actions (nothing in unxed/f4 itself changes yet). No nightly artifacts for these three are published from unxed/f4's own release pipeline, so there is nothing in the table above for them — here are the most useful current links instead.

• Redox OS — builds for GOOS=redox GOARCH=amd64 and runs in the console (panels, F-keys, Help, menu, built-in shell) and over the pure-Go X11 backend, verified by f4-redox.yml. No standalone binary is published yet — see the sandbox README for build steps and screenshots.
• GNU Hurd — builds for GOOS=hurd and runs in the console and over the pure-Go X11 backend. A prebuilt binary from the last verified run is available at unxed/debian-hurd poc/f4/f4.gz (stripped, ~27 MB gzipped) — enthusiasts on Debian GNU/Hurd can try it directly; everyone else, see the sandbox README for how it's built.
• Haiku — builds for GOOS=haiku GOARCH=amd64 and has run in a real Haiku VM (native Terminal, directory navigation, PTY-backed shell commands), verified by f4-haiku.yml. This one is the least stable of the three right now — check that workflow's recent runs before relying on it. No standalone binary is published yet.

None of these three has reached the point of a maintained, always-current downloadable build; treat them as a moving snapshot of in-progress porting work, not a supported release channel.

Philosophy & Goals

This project is built around several core philosophical and technical principles:

1. The Go Experiment: Testing the viability of building a heavy-duty TUI in Go. Go provides cross-platform compilation out of the box, fast development, and zero dependency hell (e.g., an x64 Linux binary runs on any x64 Linux without external library issues).
2. AI-only. Canaries included: Every line of code in this project is AI-generated. Instead of manually reviewing every change, we rely on an extensive test suite that serves as canaries in a coal mine: if the AI breaks something, the tests fail first. If you'd like to contribute, please include tests with your changes whenever possible.
3. Far Heritage: Copying all successful concepts from Far (screen buffer, frame manager, etc.). Keeping internal structures and their names as close to the original C++ versions as possible to lower the entry barrier for developers familiar with Far APIs.
4. Consistent UX: Adherence to a strict set of Navigation and Interaction Guidelines that blend the best of classic TUI paradigms.
5. Bazaar Policy: Openness to community contributions and patches.

Trade-offs: The compiled binary is currently ~110MB, which might not fit in highly constrained environments like home routers.

UI & Input

UI & input libraries are developed separately (vtui, vtinput)

• Modern Terminals Only: Primary target is actively developed terminals (Konsole, kitty, iTerm2, Windows Terminal). Other terminals won't allow replicating Far's UI accurately.
• Input (vtinput): Built as a separate library to handle advanced protocols like the Kitty Keyboard Protocol and Win32 Input Mode. This is strictly required for distinguishing combinations like Ctrl+Enter or Shift+Tab.
• Framework (vtui): A custom UI framework built from scratch in the style of Far, borrowing responsive layout features (like window resizing and anchors) from Turbo Vision. Ideally, it should cover all capabilities of Far's UI kit and Turbo Vision (excluding non-relevant features like custom serialization engines).
• Word Navigation: Ctrl+Left/Ctrl+Right and their Shift variants follow the exact word boundary rules of far2l, down to its intentional asymmetry between moving and selecting. See Word Navigation Rules.
• Command Palette: Ctrl+Shift+P finds any command by name and shows the key it sits on. On legacy terminals that cannot distinguish Ctrl+Shift+letter, use the built-in Ctrl+Alt+P fallback; both need no configuration and make the palette the first answer to "my terminal ate that shortcut".
• Changing Keys: Options > Hotkey Configuration rebinds a command: pick it in the list, press Assign, press the new chord. Under it sits keymap.ini, which substitutes one key for another before f4 looks at the event — for chords a multiplexer (tmux, zellij, screen) claims first, for keyboards with no F-row, and for keys that belong to a dialog rather than to a command. See Key Remapping.

GUI Mode & Backends

f4 can run either directly in your terminal or as a standalone graphical window. GUI mode is particularly useful on Windows to bypass console limitations or on Linux/macOS for high-performance hardware-accelerated rendering.

Command Line Options:

• f4 [path1 [path2]]: Open the folders in the left and right panels. A path that names a file opens the file in the viewer, as F3 would, and its panel shows the file's folder with the cursor on it.
• -e <file>, --edit <file>: Open the file in the editor.
• --gui: Start in GUI mode using the best available backend for your OS.
• --gui=win32: Use native Win32/GDI graphical windowing (Windows and Wine).
• --gui=gogpu: Use the hardware-accelerated (GPU) renderer.
• --gui=x11: Use native X11 windowing (Linux/BSD/macOS).
• --gui=wayland: Use native Wayland windowing (Linux/BSD).
• --gui=ebiten: Use the portable Ebitengine graphical backend (Windows/Linux/macOS).
• --gui=cocoa: Use the native AppKit window (macOS only); needs no XQuartz and no GPU stack.
• --tty=ansi: Force terminal mode with ANSI input/output.
• --tty=win32: Force terminal mode with the Windows Console API (winapi is an alias).
• --gui=auto / --tty=auto: Ignore the configured default backend for this run and detect one.

The available backends and their main characteristics are:

Backend or mode	Platforms	Characteristics
--gui=win32	Windows, Wine	Native Win32 window and GDI rendering; does not require ConPTY.
--gui=gogpu	Platforms supported by gogpu	Hardware-accelerated rendering when the required graphics stack is available.
--gui=x11	X11 desktops (Linux/BSD/macOS)	Native X11 windowing.
--gui=wayland	Linux/BSD with Wayland	Native Wayland windowing.
--gui=ebiten	Windows/Linux/macOS	Portable graphical fallback with no gogpu stack requirement.
--gui=cocoa	macOS	Native AppKit window; the automatic default there when gogpu is unavailable, including every lite build.
--tty=ansi	ANSI-compatible terminals	Renders through the terminal's byte stream.
--tty=win32 (winapi)	Windows and Wine consoles	Uses the Windows Console API; useful when ConPTY is unavailable.
Panel.ConsoleMode = host	Host terminals with PTY support	Sends the shell to the host terminal for native scrollback, selection, and job control; f4 falls back to a simple execution mode when a PTY is unavailable.

Example:

./f4 --gui=gogpu

Configured defaults:

To avoid repeating the same switch on every start, the choice can be saved in settings.ini under Options > Startup settings (or by hand):

[Startup]
Mode = gui          ; auto (detect, the default), tty, or gui
GuiBackend = gogpu  ; empty means detect; win32, gogpu, ebiten, x11, wayland, cocoa
TTYBackend =        ; empty means detect; ansi, winapi

Mode decides which renderer family f4 opens when neither --gui nor --tty is given, and the two backend keys say which renderer that family uses. They are only defaults: the command line still wins on any individual run, and --gui=auto / --tty=auto fall back to detection for that run. A configured backend that turns out to be unusable on the current machine falls back to automatic selection rather than preventing f4 from starting.

Portable Mode

Like Far Manager 3, f4 can keep its whole profile next to the binary instead of in the per-user directory (%APPDATA%\f4, ~/.config/f4, ...). Drop an f4.ini (shared by f4 and f4-gui) or <binary>.ini (e.g. f4.exe.ini) beside the executable:

[General]
UseSystemProfiles = 0
;Profile = %F4HOME%\Profile   ; optional; F4HOME is the binary's directory

Settings, history, Macros/scripts, plugring, styles and crash logs then live under Profile/ (or the Profile= directory) and the folder can be copied to another machine as is. A commented f4.example.ini ships with every release; Options > Portable mode inside f4 writes the ini for you and offers to copy the current profile over. The switch applies on the next start — the ini is read before the profile is located, so the mode cannot be stored inside the profile itself. F4_GENERAL_USE_SYSTEM_PROFILES=0 in the environment does the same for a single run.

Integrated Terminal & OS Integration

• Built-in Terminal: A fully-fledged built-in terminal running underneath the panels, just like far2l.
• VTE Mirror Architecture: The built-in terminal maintains its own parsed grid, while host-console mode can mirror the same PTY stream directly to the terminal. Read the Terminal Architecture Guide for details.
• Windows Strategy: f4 supports both recent Windows terminals and environments where ConPTY is unavailable. Native Windows console mode uses the Windows Console API, and the Win32/GDI GUI backend works without a host terminal; under Wine, f4 can use the same Win32 GUI path or the win32/winapi console backend. ConPTY is therefore an optional integration path, not a prerequisite for running f4 on Windows.

Plugin Architecture (Out-of-Process RPC)

f4 uses an ultra-lean, Out-of-Process plugin model communicating via stdin/stdout using the MessagePack binary protocol.

1. Language Agnostic: Write plugins in Go, Python, Rust, Node.js, C++, or Lua. If it can speak MessagePack over standard I/O streams, it works.
2. Native Power: Because plugins are native external processes, they have full access to the OS (sockets, CGO, external libraries) without the severe restrictions of WASI/WASM sandboxes.
3. Lua Ecosystem Friendly: A dedicated Lua SDK Guide bridges the gap for developers accustomed to the Far3/far2m Lua API.
4. Binary Efficiency: MessagePack minimizes serialization overhead, preventing the input lag usually associated with JSON-RPC.
5. Internal Plugins: The most critical components (like NetFox or native VFS) are statically linked into the binary but use the exact same HostAPI conceptual interface.

Special Features

1. Asynchronous VFS: Built from the ground up to be non-blocking, supporting live streaming of directory contents and lazy-loading of file data. See VFS Architecture.
2. FISH+ Protocol: Remote file management that offloads indexing, searching, patching and long-running jobs to the server. See FISH+.
3. Android Filesystem: A dedicated Android drive discovers devices through the local ADB server and selects FISH+ or an ADB Sync v1/v2 fallback for the session. See Android filesystem.
4. iPhone Filesystem: The native iOS drive discovers trusted Apple devices and exposes Media, exported application containers, app groups, and crash reports through AFC, House Arrest, and CoreDevice. See iPhone filesystem.
5. Media Information: A bounded, pure-Go media metadata analyzer integrates with F11, Ctrl+Q Quick View, command prefixes, templates, macros, and remote VFS panels. See MediaInfo plugin.
6. Environment Profiles: The built-in Environment Manager applies ordered, cross-platform environment profiles to f4 and its local workspace shells. See Environment Manager plugin.
7. Custom File Highlighting: Highly flexible file highlighting system supporting glob masks, cross-platform attributes, file sizes, absolute/relative dates, cascade blending, and visual marker glyphs. See File Highlighting Guide.
8. Declarative Localization: Flexible i18n system for UI and Help files with a built-in "Ctrl+Alt+RightClick" Translator Tool. See Localization Guide.
9. FUSE Mounts: Any file system f4 can open — archives, SFTP/FTP hosts, phones — can be mounted as an ordinary directory, so that programs which know nothing about f4 can read it. See FUSE Mounts.
10. Windows Services: a panel of the services of a Windows machine, with start, stop, pause, start type, details and a remote computer. See Windows services panel.
11. .NET Assemblies: Ctrl+PgDn on a .dll or .exe shows the assembly as a read-only tree: references, types, signatures, IL, resources. See .NET assemblies.
12. PDF: F3 shows the text of a PDF, Ctrl+PgDn opens it as a tree of pages and embedded pictures. See PDF files.
13. Formulas and Mermaid diagrams: the Markdown views turn LaTeX formulas and Mermaid diagrams into readable text. See Formulas and Mermaid.
14. Remote connection types: FTP, SFTP, SCP, SMB and FISH+ (with f4 itself as the server on the remote host). See NetFox connection types.
15. Docker, Kubernetes and MongoDB panels: containers, pods and collections as drives. See Docker, Kubernetes, MongoDB.

---

Roadmap

Phase 1: Foundation (Done)

• vtinput: Advanced keyboard protocol parsing (Kitty, Win32, Legacy).
• vtui Core: CharInfo, ScreenBuf double-buffering, zero-allocation Flush().
• vtui Primitives: ScreenObject, Dialogs, Menus, Buttons, Edits, Layouts (GrowMode).

Phase 2: Core Application (Done)

• Base f4 UI: Panels, CommandLine, KeyBar, MenuBar.
• EditorView powered by an optimized Piece Table (bracketed paste, UTF-8, zero-allocation render).
• Built-in Terminal (TerminalView + ANSI Parser + Unix PTY integration).
• Plugin Manager foundation.

Phase 3: Parity (Current)

• Add far2l features starting from requested in Issues.

Phase 4: Future

• Add Far3 and far2m starting from requested in Issues.
• Flesh out HostAPI to support comprehensive wrappers for other Far verisons APIs, implement whose wrappers.
• Python plugin support.

---

Development & Contribution Guidelines

To maintain the performance and quality of f4, all contributors (including AI assistants) must adhere to these development guidelines:

1. Licensing and IP Cleanliness: f4 is licensed under the BSD 3-Clause License. Since far2l is GPL-licensed, you must not copy, translate, or adapt GPL-licensed code from far2l or Far Manager directly. All implementations of Far/far2l concepts must be clean-room, independent rewrites.
2. Rigorous Testing: Every new feature, VFS provider, or bug fix must be accompanied by automated tests. Verify your changes by running go test ./... before submitting a pull request.
3. Code Formatting: Code must be formatted strictly according to Go standards. Always run gofmt -s -w . on your changes before committing.
4. Memory Optimization: Avoid heap allocations in hot paths or loops to prevent Garbage Collection (GC) latency. Optimize hot spots creatively, utilizing local pooling or zero-allocation paradigms.
5. FFI and Native Interoperability: Avoid CGO to preserve easy cross-compilation. If native interoperability is necessary, utilize the unxed/pureffi library for fast, non-CGO FFI.
6. Language: All code, comments, documentation, and commit messages must be in English to facilitate international collaboration.
7. Plan-First & Fail-Fast: For complex tasks, start with a clear plan, break the work into incremental, logical chunks, and focus on failing fast to catch architectural flaws early.
8. Dialog Layouts (vtui AutoLayout): All new dialogs must be built using vtui AutoLayout. Existing dialogs should be gradually refactored to AutoLayout (starting with those where layout misalignment occurs on resize). For details and API reference, see the AutoLayout Engine Guide.

Recommended instruction for LLMs:

If the task is large, break it down into multiple responses and start with a plan. For complex tasks, use an iterative, incremental approach similar to Agile or RUP. Follow the "fail fast" principle. Write tests for the generated code immediately. Use English for comments and similar elements to facilitate international collaboration. Build all new dialogs using vtui AutoLayout and gradually refactor existing ones (see https://github.com/unxed/vtui/blob/main/AUTOLAYOUT.md). Keep licensing compliance in mind: for example, you cannot copy code verbatim—or nearly verbatim—from a GPL project into a BSD project; you must implement your own solution for the same problem. In garbage-collected languages, avoid allocating memory within hot loops.

---

Getting Started (Ubuntu)

1. Install Prerequisites Ensure you have Go (1.26 or newer) installed:

sudo apt update
sudo apt install golang git

2. Setup Project Clone the repository:

git clone https://github.com/unxed/f4.git
cd f4

3. Build

cd f4
go mod tidy
CGO_ENABLED=0 go build ./cmd/f4

The generated platform icons are committed to the repository, so a normal build does not need an image converter. If internal/gui/assets/icon/f4.svg is changed, regenerate PNG, ICO, ICNS, and Windows resources on any supported OS with:

go generate ./cmd/f4

4. Run

./f4

5. Debug Mode To enable detailed logging to Logs/debug.log inside the active f4 profile, run with the --debug flag:

./f4 --debug

You can also specify a custom log file using --log; an explicit path is kept unchanged:

./f4 --log /tmp/f4_trace.log

---

Architecture

Why vtui? (vtui vs. tcell + tview/cview) While tcell and tview are industry standards for Go-based terminal applications, f4 utilizes vtui to achieve a higher level of interactive performance and UX consistency tailored for heavy-duty TUIs.

Criterion	tcell + tview/cview	vtui (f4)
Layout Philosophy	Flexbox/Grid (Web-like)	GrowMode/Anchors (Win32/Turbo Vision)
Focus Handling	Linear or component-specific	Hierarchical
Keyboard	General terminfo mapping	Full-featured (kitty/win32 protocols)
Rendering	Full-widget declarative updates	Bitwise diffing (only changed cells are updated)
Target Use Case	CLI dashboards	Stateful desktop-class applications

Performance Notes

Instant Bracketed Paste To achieve near-instantaneous pasting text via terminal Paste feature for large clipboard buffers (comparable to far2l), f4 utilizes several coordinated strategies:

1. Atomic Commits: The EditorView detects PasteStart and PasteEnd events. Instead of modifying the data model byte-by-byte, it accumulates incoming text in a temporary buffer and performs a single, atomic insertion into the PieceTable.
2. Busy State Signaling: Components can signal a Busy state to the FrameManager. While busy, the UI rendering phase and terminal Flush() are entirely suppressed, eliminating visual jitter.
3. Event Draining (Burst Processing): The FrameManager implements an "event draining" loop with a micro-timeout. It aggressively consumes all pending input events from the OS buffer before attempting a single render pass.
4. Zero-Allocation Rendering: The vtui core minimizes heap allocations during the Flush() cycle, sending only the minimum necessary ANSI sequences to the terminal.

Acknowledgements

f4 is inspired by:

• Apple Auto Layout
• ConEmu
• ConPTY — Win32 Input Mode
• DN (DOS Navigator)
• Far Manager 2/3, far2l, far2m
• FreeType — auto-hinting (details, other details)
• Midnight Commander — FISH/SHELL protocol concept
• Telegram — single-binary distribution and automatic updates
• Turbo Text Editor
• Turbo Vision
• TrueType — bytecode hinting (details, other details)
• Visual Studio Code — piece table
• vtm
• Windows Console API — data types
• Windows Notepad — word wrapping