mini.files: a Miller column file explorer where you edit the filesystem as text

Miller columns, and the buffer is the interface

mini.files is described as a tool to navigate and manipulate the file system, and it is part of the mini.nvim library. The navigation model is a column view, Miller columns, which displays nested directories as a series of horizontal panes so you always see the parent, the child and the current entry at once. The manipulation model is the unusual part. Instead of a set of modal commands, you edit a text buffer, and the edits mean things. A new line reads as file or dir/ and creates that file or directory. A new line reading dir/file or dir/nested/ creates it in a descendant directory. Deleting the whole line that represents an entry deletes that entry. Changing the text to the right of an entry's icon renames it. Copying a line and pasting it into a target directory copies it, and cutting and pasting moves it. When you are done you press = and get a read confirmation dialog, confirmed with y or enter and refused with n or escape.

Rename and the other two operations go through LSP

The README states that create, delete and rename are all LSP aware, which is a distinction that separates this module from most explorers. The rename in particular is the interesting one, because a project LSP server may know how to rename a symbol in a way that is not a plain file move, for instance when a project has its own generated file layout or a virtual filesystem. The README's phrasing covers the three operations together, and the behaviour is that the module talks to the LSP protocol handlers when they are available. The practical consequence for a user is that renaming a file in an editor with a properly configured LSP may do more than move a file on disk, and that in a project with no LSP server the operation falls back to plain filesystem behaviour. The two other operations, create and delete, are covered by the same machinery.

Navigation keys, and bookmarks for the places you return to

Opening the explorer is a Lua call, and then it behaves like a buffer.

vim.pack.add({ 'https://github.com/nvim-mini/mini.files' })

That snippet is the standalone install on the main branch, and once the plugin is loaded you run the open command. Navigation is then j and k to move down and up, l to expand the entry under the cursor, which shows a directory or opens a file in the most recent window, and h to go to the parent directory. The bookmark system uses a single character: type m followed by a character to set the directory path of the focused window as that bookmark, jump to it with the single quote followed by the character, and go back to before the latest jump with two single quotes. Typing g? gives more information about the other available mappings and about bookmarks. The README also notes you can move as in any other buffer, with dollar sign, capital G and the f and t commands, which is a small thing that matters if you have muscle memory for buffer movement.

Two branches, and the difference is stability

The plugin can be installed as part of the mini.nvim library, which the README recommends, or as a standalone Git repository, and there are two branches with a meaningful difference. The main branch, which is the default, has the latest development version, and the README says all changes since the last stable release should be perceived as being in beta testing phase, meaning they have already passed alpha testing and are moderately settled. The stable branch is only updated upon releases, with code tested during the public beta testing phase in main. In practice this is the standard mini.nvim arrangement: main is where fixes land, stable is what you pin when you want a configuration that does not move under you. The standalone install differs by package manager, with vim.pack on Neovim 0.12 and newer, mini.deps before that, and lazy.nvim, each with a main and a stable variant.

Setup, configuration and one warning about Windows paths

The plugin is inert until you call its setup function, and the README puts that in bold as important. The default config block shows the shape of what you can change: a content section with a filter predicate for which file system entries to show, and further options for highlighting and UI behaviour. The configurable list in the features section covers filtering, prefixing and sorting of file system entries, the mappings used for common explorer actions, UI options such as whether to show a preview of the file or directory under the cursor, and bookmarks for quicker navigation. The preview itself is opt-in. The one platform caveat is the Windows path problem: the README warns that on Windows you might hit errors like unable to create file because the path is too long, and offers two fixes, enabling the git global config value core.longpaths true and reinstalling, or installing the plugin in a shorter path.

Linux is the tested platform, and permissions failures are silent

Two notes in the README are worth internalising before you file a bug. The module is written and thoroughly tested on Linux, and support for other platforms such as Windows or macOS is a goal but comes with no guarantee. And the module silently reacts to not enough permissions: in the case of a missing file, you check its or its parent's read permissions, and in the case of no manipulation result, you check write permissions. Silent is the operative word. Nothing appears in the message area when an operation fails because of permissions, so a file that does not get renamed is not necessarily a bug in the module. The dependency situation is light. For the full experience the README suggests the mini.icons module to show icons next to file and directory names, with a fallback to the nvim-web-devicons plugin, but it says the module still works without any of the suggestions. The repository itself is minimal, with a LICENSE, a README, a doc directory and a lua directory, and the full documentation lives in the mini.nvim tree.

Editorial conclusion

mini.files fits a Neovim user who wants a file explorer that behaves like a buffer rather than a modal widget, so that renaming is a text edit and creation is a new line, and who wants rename to go through the project's LSP handler. It does not fit a Windows user with long paths, where the README warns about filename length errors, or anyone who expects a rich preview of binary files. Verify first that your LSP setup handles file operations, read the permissions notes, because the module reacts silently to missing read and write permissions, and remember that all contributions happen in the mini.nvim repository rather than here.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nvim-mini/mini.files on GitHub
4. README