vim.tiny is what your distribution ships, and vim/vim contains no binary

vim.tiny is a different build, and it is the one most systems install

The vim on your machine and the Vim in this repository are frequently not the same program. The README describes a build compiled with a minimal feature set, typically called vim.tiny, which aims to provide a mostly POSIX-compatible vi implementation. Many Linux distributions use that build as the default vi editor, and on Mac and Linux a small version of Vim comes pre-installed. The same paragraph tells you that you still need to install Vim if you want more features.

That matters before you judge anything else about the editor. The features it advertises, multi-level undo, syntax highlighting, command line history, on-line help, spell checking, filename completion, block operations and a script language, belong to the full build. Asking for the version inside an editor is how you find out which one you have, and the difference shows up later as missing features rather than as a warning.

There is also a Graphical User Interface, and the file notes that function keys can be mapped by the user and the mouse can be used, so the editor is not confined to a keyboard-only terminal session.

The default make target is first, and make all before configure leaves CC empty

The root Makefile has two stated purposes: starting the compilation of Vim for Unix, and creating the various distribution files. Its header says that using the Makefile without an argument compiles Vim for Unix, and that make install is also possible.

The default target is not all. It is first, chosen so that the target from src/auto/config.mk is picked up properly when config has not run yet, and the comment underneath says in plain words that doing make all before configure has run can result in compiling with $(CC) empty. A second comment gives the fallback for the platforms where the wrapper misbehaves:

cd src
make [arguments]

That advice exists because of two specific platforms. On AIX, trying to run cproto or something else after Vim has been compiled causes trouble. On OS/390 the wrapper restarts configure. Every other target, from all, install and uninstall through config, proto, depend, lint, types, test, scripttests, testtiny, test_libvterm, unittests and clean, is delegated to the same directory.

Six platform README files, and a port list that stopped growing

Installation instructions are split by operating system, and the split is literal. In the repository they live in the READMEdir directory, and in an unpacked archive they sit in the top directory: README_ami.txt for Amiga, README_unix.txt for Unix, README_dos.txt for MS-DOS and MS-Windows, README_mac.txt for Macintosh, README_haiku.txt for Haiku and README_vms.txt for VMS. Other README_*.txt files exist depending on which distribution you unpacked.

The supported list in the same file is short. Vim runs under MS-Windows 7, 8, 10 and 11, macOS, Haiku, VMS and almost all flavours of UNIX. Below that sits a second list, and that one is frozen: older versions ran on MS-DOS, MS-Windows 95/98/Me/NT/2000/XP/Vista, Amiga DOS, Atari MiNT, BeOS, RISC OS and OS/2, and the file says in as many words that these are no longer maintained.

So the answer to whether this can be ported is yes in principle, since porting to other systems is described as not very difficult, and no in practice, because the set of ports anyone still works on has not grown in a long time.

Cloning vim/vim gets you runtime files, not an executable

This README.md file comes with the runtime archive, and what it brings with it is the documentation, syntax files and other files used at runtime. To run Vim you still need either one of the binary archives or a source archive, and the overview of what is currently available lives at vim.org/download.php.

Three routes are named. There is the git repository on GitHub, the source code as an archive from the tags, and a Windows executable that comes from a separate repository, vim-win32-installer, which keeps its releases there rather than here. Separate distributions exist for Unix, PC, Amiga and some other systems, and which one you need depends on the system you want to run on and on whether you want or must compile it yourself.

For anyone evaluating the source, the interesting part is src, where all the material for compiling lives, with the instructions in src/INSTALL. If you took a binary distribution, none of that applies. The top level also holds a Filelist and a configure script, which are the two files that decide what gets built where.

Unmodified redistribution is unrestricted, modified copies are not

Vim calls itself Charityware, and the licence summary is short enough to hold in your head. There are no restrictions on using or distributing an unmodified copy. Parts of Vim may also be distributed, but the licence text must always be included. For modified versions, a few restrictions apply. The licence is GPL compatible, which means you may compile Vim with GPL libraries and distribute the result.

That third sentence is the one that decides a policy. Shipping a binary you downloaded is unrestricted, shipping a build you compiled yourself is fine, and shipping a patched Vim is a different question that the summary does not answer. runtime/doc/uganda.txt holds the details and is reachable inside the editor with :help uganda. The LICENSE file at the top level is the other place to look.

The donation request lives in the same documents. The money is described as going mainly to help children in Uganda, with the note that donations also increase the development team's motivation, and the sponsoring page is at vim.org/sponsor/. Most of Vim was created by Bram Moolenaar.

The manual is inside the product, and the entry point depends on the binary

Documentation ships inside the editor, which is unusual and mostly a good thing. The entry point depends on what you have. Without an executable, read runtime/doc/help.txt, which contains pointers to the other documentation files. With one, the advice is to use :help, and the User Manual reads like a book and is recommended for learning the editor, reachable at :help user-manual.

Beginners start somewhere else. The Vim tutor is a one hour training course for beginners, and it is often started from a shell:

vimtutor

:help tutor has more on it. The repository also carries vimtutor.bat and vimtutor.com at the top level, so the same course is reachable on systems where that shell command is not the obvious way in.

One more file matters for anyone arriving from Vi. runtime/doc/vi_diff.txt is where the differences with Vi are written down, and the claim that those who have Vi in the fingers will feel at home is qualified by the existence of that file.

No releases, so the version number lives inside the editor

There is no release feed in this repository. No GitHub releases are published, so there is nothing to subscribe to and no tag to diff against, even though the tags page is offered as a way to get the source as an archive. The version lives inside the product instead. This README.md is the one for version 9.2 of Vim, and the same string is what the in-editor help reports.

The freshness signal is the branch. The last push to master was on 2026-09-28, and the badges at the top of the file point at a GitHub CI workflow, codecov, Coverity, a Debian build daemon, Repology and a codespell run, so the checks exist even though the releases do not. There is a ci/ directory in the tree, along with AGENTS.md, SECURITY.md, .clang-format, .editorconfig, a .codecov.yml and a .git-blame-ignore-revs that keeps formatting commits out of blame.

For a user that splits into two situations. A distribution package arrives with a version and a maintenance window attached to the distribution. A build from master arrives with the current state and no history, which is why src/INSTALL and the Filelist matter more here than they would in a project with tags. Bugs go to the vim-dev mailing list.

MacVim and vim-win32-installer are the two builds kept beside the editor

Two alternatives are named in the repository itself, and they answer different questions. For macOS, MacVim is the pointer, which is a graphical build rather than the terminal editor, so somebody who wants a window on that platform is not expected to compile the terminal version first. For Windows, the executable comes from the separate vim-win32-installer repository, the same idea in a different shape: the packaged build is maintained next to the editor rather than inside it.

The older alternative is Vi itself, and compatibility is deliberate rather than accidental. The feature list, from multi-level undo to block operations, is framed as additions to the old editor, and the promise is that Vi muscle memory carries over. The honest form of that claim is in runtime/doc/vi_diff.txt, which is short enough that anyone whose hands still type Vi commands should read it before deciding the compatibility is complete.

Neither of the three changes the licensing position described above, and neither is a fork. All of them are the same source tree with a different build around it.

Editorial conclusion

Vim fits someone who wants a POSIX vi implementation with multi-level undo, on-line help and a script language, on a system where installing a full build is possible. It does not fit a team that expects tagged releases, because this repository publishes none and the version lives in the help files. Verify first which binary is already on your PATH, because the Vim pre-installed on Mac and Linux is a small build, then read src/INSTALL before compiling and runtime/doc/vi_diff.txt if you are arriving from Vi.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository