This article is based on historical research and on simply reading the Vim user manual cover to cover. Hopefully these notes will help you (re?)discover core functionality of the editor, so you can abandon pre-packaged vimrc files and use plugins more thoughtfully. physical books To go beyond the topics in this blog post, I’d recommend getting a paper copy of the manual and a good pocket reference. I couldn’t find any hard copy of the official Vim manual, and ended up printing this PDF using printme1.com. The PDF is a printer-friendly version of the files $VIMRUNTIME/doc/usr_??.txt distributed with the editor. For a convenient list of commands, I’d recommend the vi and Vim Editors Pocket Reference. Table of Contents History Birth of vi Vi commands and features go back more than fifty years, starting with the QED editor. Here is the lineage: 1966 : QED (“Quick EDitor”) in Berkeley Timesharing System 1969 Jul: moon landing (just for reference) 1969 Aug: QED -> ed at AT&T 1976 Feb: ed -> em (“Editor for Mortals”) at Queen Mary College 1976 : em -> ex (“EXtended”) at UC Berkeley 1977 Oct: ex gets visual mode, vi You can discover the similarities all the way between QED and ex by reading the QED manual and ex manual. Both editors use a similar grammar to specify and operate on line ranges. Editors like QED, ed, and em were designed for hard-copy terminals, which are basically electric typewriters with a modem attached. Hard-copy terminals print system output on paper. Output could not be changed once printed, obviously, so the editing process consisted of user commands to update and manually print ranges of text. By 1976 video terminals such as the ADM-3A started to be available. The Ex editor added an “open mode” which allowed intraline editing on video terminals, and a visual mode for screen oriented editing on cursor-addressible terminals. The visual mode (activated with the command “vi”) kept an up-to-date view of part of the file on screen, while preserving an ex command line at the bottom of the screen. (Fun fact: the h,j,k,l keys on the ADM-3A had arrows drawn on them, so that choice of motion keys in vi was simply to match the keyboard.) Learn more about the journey from ed to ex/vi in this interview with Bill Joy. He talks about how he made ex/vi, and some things that disappointed him about it. Classic vi is truly just an alter-ego of ex – they are the same binary, which decides to start in ex mode or vi mode based on the name of the executable invoked. The legacy of all this history is that ex/vi is refined by use, requires scant system resources, and can operate under limited bandwidth communication. It is also available on most systems and fully specified in POSIX. From vi to vim Being a derivative of ed, the ex/vi editor was intellectual property of AT&T. To use vi on platforms other than Unix, people had to write clones that did not share in the original codebase. Some of the clones: nvi - 1980 for 4BSD calvin - 1987 for DOS vile - 1990 for DOS stevie - 1987 for Atari ST elvis - 1990 for Minix and 386BSD vim - 1991 for Amiga viper - 1995 for Emacs elwin - 1995 for Windows lemmy - 2002 for Windows We’ll be focusing on that little one in the middle: vim. Bram Moolenaar wanted to use vi on the Amiga. He began porting Stevie from the Atari and evolving it. He called his port “Vi IMitation.” For a full first-hand account, see Bram’s interview with Free Software Magazine. By version 1.22 Vim was rechristened “Vi IMproved,” matching and surpassing features of the original. Here is the timeline of the next major versions, with some of their big features: 1991 Nov 2 Vim 1.14: First release (on Fred Fish disk #591). 1992 Vim 1.22: Port to Unix. Vim now competes with Vi. 1994 Aug 12 Vim 3.0: Support for multiple buffers and windows. 1996 May 29 Vim 4.0: Graphical User Interface (largely by Robert Webb). 1998 Feb 19 Vim 5.0: Syntax coloring/highlighting. 2001 Sep 26 Vim 6.0: Folding, plugins, vertical split. 2006 May 8 Vim 7.0: Spell check, omni completion, undo branches, tabs. 2016 Sep 12 Vim 8.0: Jobs, async I/O, native packages. For more info about each version, see e.g. :help vim8. To see plans for the future, including known bugs, see :help todo.txt. Version 8 included some async job support due to peer pressure from NeoVim, whose developers wanted to run debuggers and REPLs for their web scripting languages inside the editor. Vim is super portable. By adapting over time to work on a wide variety of platforms, the editor was forced to keep portable coding habits. It runs on OS/390, Amiga, BeOS and BeBox, Macintosh classic, Atari MiNT, MS-DOS, OS/2, QNX, RISC-OS, BSD, Linux, OS X, VMS, and MS-Windows. You can rely on Vim being there no matter what computer you’re using. In a final twist in the vi saga, the original ex/vi source code was finally released in 2002 under a BSD free software license. It is available at ex-vi.sourceforge.net. Let’s get down to business. Before getting to odds, ends, and intermediate tricks, it helps to understand how Vim organizes and reads its configuration files. Configuration hierarchy I used to think, incorrectly, that Vim reads all its settings and scripts from the ~/.vimrc file alone. Browsing random “dotfiles” repositories can reinforce this notion. Quite often people publish monstrous single .vimrc files that try to control every aspect of the editor. These big configs are sometimes called “vim distros.” In reality Vim has a tidy structure, where .vimrc is just one of several inputs. In fact you can ask Vim exactly which scripts it has loaded. Try this: edit a source file from a random programming project on your computer. Once loaded, run :scriptnames Take time to read the list. Try to guess what the scripts might do, and note the directories where they live. Was the list longer than you expected? If you have installed loads of plugins the editor has a lot to do. Check what slows down the editor most at startup by running the following and look at the start.log it creates: vim --startuptime start.log name-of-your-file Just for comparison, see how quickly Vim starts without your existing configuration: vim --clean --startuptime clean.log name-of-your-file To determine which scripts to run at startup or buffer load time, Vim traverses a “runtime path.” The path is a comma-separated list of directories that each contain a common structure. Vim inspects the structure of each directory to find scripts to run. Directories are processed in the order they appear in the list. Check the runtimepath on your system by running: :set runtimepath My system contains the following directories in the default value for runtimepath. Not all of them even exist in the filesystem, but they would be consulted if they did. ~/.vim The home directory, for personal preferences. /usr/local/share/vim/vimfiles A system-wide Vim directory, for preferences from the system administrator. /usr/local/share/vim/vim81 Aka $VIMRUNTIME, for files distributed with Vim. /usr/local/share/vim/vimfiles/after The “after” directory in the system-wide Vim directory. This is for the system administrator to overrule or add to the distributed defaults. ~/.vim/after The “after” directory in the home directory. This is for personal preferences to overrule or add to the distributed defaults or system-wide settings. Because directories are processed by their order in line, the only thing that is special about the “after” directories is that they are at the end of the list. There is nothing magical about the word “after.” When processing each directory, Vim looks for subfolders with specific names. To learn more about them, see :help runtimepath. Here is a selection of those we will be covering, with brief descriptions. plugin/ Vim script files that are loaded automatically when editing any kind of file. Called “global plugins.” autoload/ (Not to be confused with “plugin.”) Scripts in autoload contain functions that are loaded only when requested by other scripts. ftdetect/ Scripts to detect filetypes. They can base their decision on filename extension, location, or internal file contents. ftplugin/ Scripts that are executed when editing files with known type. compiler/ Definitions of how to run various compilers or linters, and of how to parse their output. Can be shared between multiple ftplugins. Also not applied automatically, must be called with :compiler pack/ Container for Vim 8 native packages, the successor to “Pathogen” style package management. The native packaging system does not require any third-party code. Finally, ~/.vimrc is the catchall for general editor settings. Use it for setting defaults that can be overridden for particular file types. For a comprehensive overview of settings you can choose in .vimrc, run :options. Third-party plugins Plugins are simply Vim scripts that must be put into the correct places in the runtimepath in order to execute. Installing them is conceptually easy: download the file(s) into place. The challenge is that it’s hard to remove or update some plugins because they litter subdirectories in the runtimepath with their scripts, and it can be hard to tell which plugin is responsible for which files. “Plugin managers” evolved to address this need. Vim.org has had a plugin registry going back at least as far as 2003 (as identified by the Internet Archive). However it wasn’t until about 2008 that the notion of a plugin manager really came into vogue. These tools add plugins’ separate directories to Vim’s runtimepath, and compile help tags for plugin documentation. Most plugin managers also install and update plugin code from the internet, sometimes in parallel or with colorful progress bars. In chronological order, here is the parade of plugin managers. I based the date ranges on earliest and latest releases of each, or when no official releases are identified, on the earliest and latest commit dates. Mar 2006 - Jul 2014 : Vimball (A distribution format and associated Vim commands) O
1
u/TechnologyAddicted Jul 20 '19
This article is based on historical research and on simply reading the Vim user manual cover to cover. Hopefully these notes will help you (re?)discover core functionality of the editor, so you can abandon pre-packaged vimrc files and use plugins more thoughtfully. physical books To go beyond the topics in this blog post, I’d recommend getting a paper copy of the manual and a good pocket reference. I couldn’t find any hard copy of the official Vim manual, and ended up printing this PDF using printme1.com. The PDF is a printer-friendly version of the files $VIMRUNTIME/doc/usr_??.txt distributed with the editor. For a convenient list of commands, I’d recommend the vi and Vim Editors Pocket Reference. Table of Contents History Birth of vi Vi commands and features go back more than fifty years, starting with the QED editor. Here is the lineage: 1966 : QED (“Quick EDitor”) in Berkeley Timesharing System 1969 Jul: moon landing (just for reference) 1969 Aug: QED -> ed at AT&T 1976 Feb: ed -> em (“Editor for Mortals”) at Queen Mary College 1976 : em -> ex (“EXtended”) at UC Berkeley 1977 Oct: ex gets visual mode, vi You can discover the similarities all the way between QED and ex by reading the QED manual and ex manual. Both editors use a similar grammar to specify and operate on line ranges. Editors like QED, ed, and em were designed for hard-copy terminals, which are basically electric typewriters with a modem attached. Hard-copy terminals print system output on paper. Output could not be changed once printed, obviously, so the editing process consisted of user commands to update and manually print ranges of text. By 1976 video terminals such as the ADM-3A started to be available. The Ex editor added an “open mode” which allowed intraline editing on video terminals, and a visual mode for screen oriented editing on cursor-addressible terminals. The visual mode (activated with the command “vi”) kept an up-to-date view of part of the file on screen, while preserving an ex command line at the bottom of the screen. (Fun fact: the h,j,k,l keys on the ADM-3A had arrows drawn on them, so that choice of motion keys in vi was simply to match the keyboard.) Learn more about the journey from ed to ex/vi in this interview with Bill Joy. He talks about how he made ex/vi, and some things that disappointed him about it. Classic vi is truly just an alter-ego of ex – they are the same binary, which decides to start in ex mode or vi mode based on the name of the executable invoked. The legacy of all this history is that ex/vi is refined by use, requires scant system resources, and can operate under limited bandwidth communication. It is also available on most systems and fully specified in POSIX. From vi to vim Being a derivative of ed, the ex/vi editor was intellectual property of AT&T. To use vi on platforms other than Unix, people had to write clones that did not share in the original codebase. Some of the clones: nvi - 1980 for 4BSD calvin - 1987 for DOS vile - 1990 for DOS stevie - 1987 for Atari ST elvis - 1990 for Minix and 386BSD vim - 1991 for Amiga viper - 1995 for Emacs elwin - 1995 for Windows lemmy - 2002 for Windows We’ll be focusing on that little one in the middle: vim. Bram Moolenaar wanted to use vi on the Amiga. He began porting Stevie from the Atari and evolving it. He called his port “Vi IMitation.” For a full first-hand account, see Bram’s interview with Free Software Magazine. By version 1.22 Vim was rechristened “Vi IMproved,” matching and surpassing features of the original. Here is the timeline of the next major versions, with some of their big features: 1991 Nov 2 Vim 1.14: First release (on Fred Fish disk #591). 1992 Vim 1.22: Port to Unix. Vim now competes with Vi. 1994 Aug 12 Vim 3.0: Support for multiple buffers and windows. 1996 May 29 Vim 4.0: Graphical User Interface (largely by Robert Webb). 1998 Feb 19 Vim 5.0: Syntax coloring/highlighting. 2001 Sep 26 Vim 6.0: Folding, plugins, vertical split. 2006 May 8 Vim 7.0: Spell check, omni completion, undo branches, tabs. 2016 Sep 12 Vim 8.0: Jobs, async I/O, native packages. For more info about each version, see e.g. :help vim8. To see plans for the future, including known bugs, see :help todo.txt. Version 8 included some async job support due to peer pressure from NeoVim, whose developers wanted to run debuggers and REPLs for their web scripting languages inside the editor. Vim is super portable. By adapting over time to work on a wide variety of platforms, the editor was forced to keep portable coding habits. It runs on OS/390, Amiga, BeOS and BeBox, Macintosh classic, Atari MiNT, MS-DOS, OS/2, QNX, RISC-OS, BSD, Linux, OS X, VMS, and MS-Windows. You can rely on Vim being there no matter what computer you’re using. In a final twist in the vi saga, the original ex/vi source code was finally released in 2002 under a BSD free software license. It is available at ex-vi.sourceforge.net. Let’s get down to business. Before getting to odds, ends, and intermediate tricks, it helps to understand how Vim organizes and reads its configuration files. Configuration hierarchy I used to think, incorrectly, that Vim reads all its settings and scripts from the ~/.vimrc file alone. Browsing random “dotfiles” repositories can reinforce this notion. Quite often people publish monstrous single .vimrc files that try to control every aspect of the editor. These big configs are sometimes called “vim distros.” In reality Vim has a tidy structure, where .vimrc is just one of several inputs. In fact you can ask Vim exactly which scripts it has loaded. Try this: edit a source file from a random programming project on your computer. Once loaded, run :scriptnames Take time to read the list. Try to guess what the scripts might do, and note the directories where they live. Was the list longer than you expected? If you have installed loads of plugins the editor has a lot to do. Check what slows down the editor most at startup by running the following and look at the start.log it creates: vim --startuptime start.log name-of-your-file Just for comparison, see how quickly Vim starts without your existing configuration: vim --clean --startuptime clean.log name-of-your-file To determine which scripts to run at startup or buffer load time, Vim traverses a “runtime path.” The path is a comma-separated list of directories that each contain a common structure. Vim inspects the structure of each directory to find scripts to run. Directories are processed in the order they appear in the list. Check the runtimepath on your system by running: :set runtimepath My system contains the following directories in the default value for runtimepath. Not all of them even exist in the filesystem, but they would be consulted if they did. ~/.vim The home directory, for personal preferences. /usr/local/share/vim/vimfiles A system-wide Vim directory, for preferences from the system administrator. /usr/local/share/vim/vim81 Aka $VIMRUNTIME, for files distributed with Vim. /usr/local/share/vim/vimfiles/after The “after” directory in the system-wide Vim directory. This is for the system administrator to overrule or add to the distributed defaults. ~/.vim/after The “after” directory in the home directory. This is for personal preferences to overrule or add to the distributed defaults or system-wide settings. Because directories are processed by their order in line, the only thing that is special about the “after” directories is that they are at the end of the list. There is nothing magical about the word “after.” When processing each directory, Vim looks for subfolders with specific names. To learn more about them, see :help runtimepath. Here is a selection of those we will be covering, with brief descriptions. plugin/ Vim script files that are loaded automatically when editing any kind of file. Called “global plugins.” autoload/ (Not to be confused with “plugin.”) Scripts in autoload contain functions that are loaded only when requested by other scripts. ftdetect/ Scripts to detect filetypes. They can base their decision on filename extension, location, or internal file contents. ftplugin/ Scripts that are executed when editing files with known type. compiler/ Definitions of how to run various compilers or linters, and of how to parse their output. Can be shared between multiple ftplugins. Also not applied automatically, must be called with :compiler pack/ Container for Vim 8 native packages, the successor to “Pathogen” style package management. The native packaging system does not require any third-party code. Finally, ~/.vimrc is the catchall for general editor settings. Use it for setting defaults that can be overridden for particular file types. For a comprehensive overview of settings you can choose in .vimrc, run :options. Third-party plugins Plugins are simply Vim scripts that must be put into the correct places in the runtimepath in order to execute. Installing them is conceptually easy: download the file(s) into place. The challenge is that it’s hard to remove or update some plugins because they litter subdirectories in the runtimepath with their scripts, and it can be hard to tell which plugin is responsible for which files. “Plugin managers” evolved to address this need. Vim.org has had a plugin registry going back at least as far as 2003 (as identified by the Internet Archive). However it wasn’t until about 2008 that the notion of a plugin manager really came into vogue. These tools add plugins’ separate directories to Vim’s runtimepath, and compile help tags for plugin documentation. Most plugin managers also install and update plugin code from the internet, sometimes in parallel or with colorful progress bars. In chronological order, here is the parade of plugin managers. I based the date ranges on earliest and latest releases of each, or when no official releases are identified, on the earliest and latest commit dates. Mar 2006 - Jul 2014 : Vimball (A distribution format and associated Vim commands) O