What “Hackable” Means for xplr, the TUI File Explorer

xplr is a terminal (TUI) file explorer that describes itself as “hackable, minimal, fast.” In practice, “hackable” means the tool is built to be reshaped by you: its behavior, keybindings, layout, and integrations are meant to be configured and extended rather than accepted as a fixed product. That makes it a good fit if you already work in a terminal and want a file explorer that follows your workflow; it is a poor fit if you want a polished, zero-setup file manager with a fixed set of menus and defaults.

The core idea: configuration is the product

Most file managers ship a complete interaction model—fixed keybindings, fixed panes, fixed preview behavior—and your only real choice is whether to use it. xplr takes the opposite stance. The website frames it as “hackable, minimal, fast,” and the presence of a dedicated Documentation section alongside Features, Blog, and GitHub signals that learning the configuration surface is part of using the tool, not an optional extra.

So “hackable” is not a marketing word for “has a settings menu.” It means the explorer's behavior is something you assemble and adjust. The practical consequence: expect to read the documentation and write configuration before xplr feels like your file explorer.

What you can actually adapt

Based on how xplr presents itself, the customization surface centers on the things that define a TUI explorer's feel:

• Keybindings and modes — how you move, select, open, and switch context.
• Layout and UI behavior — what the interface shows and how it responds.
• Integration with your environment — how it hands off to other terminal tools and scripts.

The exact set of options is defined in xplr's documentation, which is the authoritative place to check before you commit. Treat any specific configuration key or command as something to verify there rather than assume.

A concrete example of the difference

Suppose your workflow is: browse a directory, preview a file, then open it in your editor of choice. A fixed file manager gives you one built-in way to do that, and you adapt to it. With a hackable explorer, the task becomes: define which key triggers the preview, define which key launches your editor with the selected path, and decide how the result appears. The work moves from “learn the app's way” to “describe your way once, then reuse it.” That is the trade: upfront configuration in exchange for an interface that matches how you already work.

How to decide whether it suits you

Getting started without guessing

The site offers two entry points: Try and Install. Use “Try” to evaluate the interaction model before investing in configuration, and “Install” when you are ready to set it up properly. Because the tool is explicitly hackable, plan your first session around the documentation rather than around discovering menus—the docs are where the configuration options and their behavior are defined.

A sensible sequence:

1. Try it to confirm the TUI model fits how you work.
2. Read the documentation for the configuration options relevant to your habits (keys, layout, integrations).
3. Write a minimal configuration for one real task—for example, previewing and opening files—and verify it behaves as expected.
4. Expand only when a specific need appears.

The common pitfall is treating xplr like a fixed file manager and judging it on out-of-the-box behavior. Its value shows up after configuration, so evaluate it on how well it adapts, not on first launch.