Vifm: a Vim-like curses file manager for people who already live in Vim

What Vifm solves for Vim users

The README states the premise plainly: if you use Vim, Vifm gives you complete keyboard control over your files without having to learn a new set of commands. That is a narrower claim than "better file manager", and it is the honest one. The cost of most terminal file managers is the vocabulary. You learn a new key for renaming, a new key for copying, a new way to select a range of files. Vifm instead asks you to reuse what you already know from Vim: modes, options, registers and commands. The README is explicit that this goes beyond keybindings.

The target user is therefore specific. Someone who edits in Vim, keeps a .vimrc, and thinks in terms of Normal mode and command-line mode will find Vifm's model already loaded. Someone who uses a graphical editor and occasionally opens a terminal will spend their first hour fighting the mode system for no benefit. Vifm also borrows ideas from mutt, which is a hint about its lineage: two panes, a command line, and heavy configuration rather than a fixed feature set.

The README frames this as Unix philosophy. Instead of set-in-stone solutions, Vifm provides means for customization, while claiming builtin functionality should cover most use cases. That is a fair description of the trade-off, though the second half of the sentence is doing more work than the first: the defaults are usable, but the project's identity lives in the configuration.

How the two-pane curses interface and Vim modes fit together

Vifm is a curses application written in C, so it draws into the terminal rather than opening a window. The interface is two panes, which is the mutt inheritance, and the interaction model is Vim's. The README points new users at the cheatsheet for Normal mode, which tells you where the centre of gravity is: Normal mode is the mode you are supposed to live in, and other modes are entered deliberately.

Configuration is a first-class part of the architecture rather than an afterthought. The README's quick-start advice includes running :edit $MYVIFMRC, which opens the sample configuration file. That single command reveals the design: the file is meant to be read and edited, and the environment variable is the entry point to it. The repository also ships a data/ directory, and the README links to separate repositories for colorschemes, a Vim plugin, devicons, and several image preview projects. Those are external, which matters when you evaluate how much of the polished experience is maintained by the core project versus by third parties.

On the repository side, there is a ChangeLog.LuaAPI file at the top level alongside ChangeLog. That indicates a Lua API surface with its own change history, separate from the main changelog. The README does not document that API, so anyone planning to script Vifm should treat the top-level files and the wiki as the sources to check rather than assuming the README covers it.

Installing Vifm and opening your first directory

The README lists package manager commands for a long set of platforms. On Debian and derivatives the command is apt install vifm, and on Fedora and derivatives it is dnf install vifm or yum install vifm. macOS users get brew install vifm or port install vifm. There is no build-from-source tutorial in the README itself; the repository has an INSTALL file and a configure script at the top level, which is where a source build would start, but the README steers you to packages first.

apt install vifm

After installation, running vifm opens the two-pane interface. The README suggests skimming the cheatsheet for Normal mode as the quickest way in, and reading basic usage sections on the wiki. If your distribution ships an old version, the README offers an AppImage path for Linux systems younger than 10 years with a FUSE-capable kernel, downloaded and marked executable. The curl and sed variant is given verbatim:

curl -Lso ~/.local/bin/vifm \
    "https://github.com/vifm/vifm/releases/latest/download/vifm-v$(
        curl -Ls "https://api.github.com/repos/vifm/vifm/releases/latest" |
        sed -nE '/"tag_name":/s/.*"v*([^"]+)".*/\1/p'
    )-x86_64.AppImage" && chmod +x ~/.local/bin/vifm

The README notes a real constraint on that route: helpers like vifm-pause, which is used by :!!, are not accessible in the AppImage before v0.15. So the AppImage is a way to get a newer binary than your distribution offers, but not a complete substitute for a packaged install if you rely on those helpers.

Once inside, the first configuration step the README names is opening the sample config:

:edit $MYVIFMRC

That opens the sample configuration file for editing in place, which is the intended starting point for customisation.

Where Vifm is the wrong tool

The clearest limitation is the one the README implies rather than states: Vifm assumes you understand Vim's nature. The README says how well Vifm serves you depends in part on how well you understand that, and it recommends two outside essays, Bram Moolenaar's "Seven habits of effective text editing" and Jim Dennis's "Your problem with Vim is that you don't grok vi". Recommending background reading before a file manager becomes pleasant is an admission that the learning curve is real and front-loaded.

The AppImage caveat is a second concrete boundary. Before v0.15, vifm-pause and the helpers that depend on it are unavailable in the AppImage, so shell command output handling through :!! behaves differently depending on how you installed. That is the kind of discrepancy that makes bug reports hard to compare across users.

A third issue is version lag. The most recent release listed is v0.14.4 from 2026-05-31, but the README's own header says "Version 0.15", and the AppImage note refers to v0.15 as a future threshold for the helpers. Distribution packages commonly trail upstream, so the version you install from apt or dnf may not match the features described in current documentation. Check the version your package provides before concluding that a documented feature is missing.

Finally, Vifm is a terminal application. If you need thumbnails, drag and drop, or a file picker that integrates with a desktop environment, none of that is in scope. The image preview options the README lists are separate third-party repositories built on Überzug, Sixel, or Kitty protocols, which means image preview depends on your terminal as much as on Vifm.

Vifm compared with ranger and Yazi

The comparison people search for is Vifm versus ranger, and the difference is the interaction model rather than the feature list. Ranger is built around a Miller-column layout with a single active column and a preview pane, and its keybindings are its own. Vifm keeps two panes side by side, in the mutt tradition, and its bindings come from Vim. If you have Vim muscle memory, Vifm asks you to learn almost nothing new; ranger asks you to learn ranger.

The same distinction applies to Yazi, which is a newer terminal file manager. The README gives no comparison with either project, so the only defensible statement is about approach: Vifm's bet is that reusing Vim's modes, options, registers and commands is worth more than a fresh, self-consistent keymap. That bet pays off for a Vim user and costs a non-Vim user.

There is a second axis worth noting. Vifm is written in C and has been around long enough to accumulate a ChangeLog, a FAQ, a BUGS file and a HACKING.md at the top level, plus a separate ChangeLog.LuaAPI. Ranger and Yazi are different codebases with different extension stories. If your requirement is scripting the file manager in a language you already use, check what each project documents rather than assuming parity; the README for Vifm does not describe its Lua API surface.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-07. Releases are not frequent: v0.14.2 on 2025-05-07, v0.14.3 on 2025-06-04, and v0.14.4 on 2026-05-31. That cadence suggests a mature project that ships when there is something to ship rather than on a schedule. The README header says "Version 0.15" and was last updated on 17 June 2026, so documentation is being maintained ahead of or alongside the next release.

Upgrade cost has two parts. The first is your own configuration: because Vifm is configured through a file opened with :edit $MYVIFMRC, a major release can change option names or defaults, and the ChangeLog and NEWS files at the top level are where that would be recorded. The second is the AppImage path, where the vifm-pause limitation before v0.15 means an upgrade changes behaviour for shell commands, not just appearance.

Licensing is GNU General Public License version 2 or later, as stated in the README and reflected by the COPYING file. There is also a COPYING.3party file, which means bundled third-party code carries its own terms. If you redistribute Vifm or a modified build, the GPL obligations apply; that is a factual consequence of the licence, not legal advice, and anyone embedding Vifm in a product should read COPYING and COPYING.3party directly.

Editorial conclusion

Adopt Vifm if you already use Vim daily and want file operations to reuse the same modes, registers and command syntax rather than a separate set of shortcuts. Skip it if you need a graphical file browser, a mouse-first workflow, or a file manager you can hand to a colleague who has never opened Vim. Before committing, run :edit $MYVIFMRC to see the sample configuration, check the cheatsheet for Normal mode, and confirm your distribution's package version against the v0.14.4 release from 2026-05-31, because a stale package is the most common reason a feature you read about is missing.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. vifm/vifm on GitHub