I used data from the Vim git repository to create an annotated chart of some of the main moments in the last 20 years of Vim development.
Vim was the first text editor I've ever used (back in 2008), and it shaped the way I interact with computers forever. I'm grateful to all maintainers, and to Bram for creating it and shepherding it through all these decades.
The annotations are interactive, so if you hover them you'll see more context about the events.
> The annotations are interactive, so if you hover them you'll see more context about the events.
It would be helpful to put this somewhere on the page. On mobile especially one isn’t likely to accidentally discover this with random mouse movements.
When do most people use text editors? I think wouldn’t be that surprised if somebody fist used a text editor when they first got into Linux or programming.
It was definitely notepad to edit some obscure .ini files on some pc game, or reading a Readme on a cracked/pirated game. On windows that would be the obvious case.
Downloading something over limewire or torrent and seeing a readme file for the first time is a pretty strong memory.
My first IDE was visual studio writing Visual Basic, I quickly binned that for netbeans and Java and then I think ended up using Eclipse.
Today I’m a casual evil mode emacs user mostly for magit and org-mode. also working in VScode for web languages.
But, I also think there’s enough leeway in the idea of “using a tool” to not be surprised that somebody doesn’t count a one-off use of notepad. And I think there must exist at least some people who really never used notepad.
Nowadays I only assume someone between, like, 30 and 50 will inherently have to have used Windows at some point. Outside that range, you might get graybeards who were around before Windows, or younger folks who only ever used smartphones.
Anyway, all that rambling is to say, I’d put it in the “most but not shocking to hear otherwise” category.
They will use it, but they don’t know it’s Windows or what an OS is. They’ll just say it’s a Microsoft computer or PC. Or “not Apple”. Maybe even Android.
I mean, there exist and have always existed people who’ve never used it at home. And there exist and (ever since it came out) have existed people who have.
What I’ve tried to express is that there’s a small band where not having used it is unusual and surprising, and that isn’t the case anymore. I still think the majority of people have used Windows at least a handful of times but hearing that somebody hasn’t no longer produces a “how could anyone” sort of response.
I think they probably mean a non-modal visual/screen editor (like NotePad on Windows or TextEdit on Mac). I used pico on Unix before learning vi, for example, which is probably a common progression.
Notepad++ (Windows, 2003) / gedit (GNOME, 1998) / kwrite/kate (KDE, 2001) all existed in 2008 and are totally fine basic text editors for source code. I remember editing PHP in a more obscure editor (SciTE, 1999) on Windows in the early 2000s.
You might be surprised to learn that the original version of Vim (on the Amiga: https://www.reddit.com/r/amiga/comments/l5j53m/the_text_edit...) was a GUI based application! Ok, it didn't have much in the way of an actual GUI, but it ran in a window which wasn't the shell/CLI window. I guess the actual reason why Vim is a console application on Linux is the lack of a "standard" GUI framework.
I was thrown into vi, back in 1996, learning Linux. It was the default (or at least available) and the SuSE manual that came with the CD-ROM box had a chapter on vi/vim.
For me it was my first editor on Linux. Didn't stick until I rediscovered it some 20 years ago when I got fed up with the netbeans nonsense and gedit and Kate kept breaking on me.
Be old. I went from VMS' EDT in the late 80s to JOE (Joe's Own Editor) on Ultrix, to Emacs, and finally Vim. I finally switched to Neovim after Bram's passing.
Its complexity. Elisp is both a blessing and a curse. It's great to be able to make deep, fundamental changes to Emacs via Elisp, but sometimes, you end up wading though very difficult-to-read code trying to figure out how it works. IME, vim is less flexible, but simpler when I just want to edit code and not think about Emacsisms.
Cool tool! I had to double check because I thought Vim was much older. Indeed, Vim goes back to 1991 (https://en.wikipedia.org/wiki/Vim_(text_editor)). This is a great view of the last 20 years of Vim.
Would like to see this with the #lines/changes per commit. Its obvious that there are more commits post neovim, but i wonder if they're more substantial or just a change in work flow (eg: previously 1 commit with 3 lines, later 3 commits with 1 line each).
I wonder why that is. Just a bigger tent, with some of the benefits being committed back to vim? More pressure to bring in features from neovim pushing the pace faster? I'd be curious to hear an explanation if anyone has one.
Is anyone keeping track of what the most popular Vim commands are?
Personally, I've been using Vim for years, but I must confess that I use almost the same commands as I did in the beginning. Is there any good website that teaches useful tricks, maybe on a daily basis?
I really can't recommend Drew Neil's resources enough. The vimcasts¹ series are great if you're the sort of person who likes videos to learn with, and both his books are excellent²³. [The books may appear to be getting a little long in the tooth, but their contents are still very applicable to today's usage.]
My own "trick" for improving my vim usage was to start mapping things to <Nop> that have better replacements, it is a great way to shock yourself out of bad habits like hjkl movements or reliance on /. Then again, I think text-objects and the items below it in motion.txt are the main to use vim so YMMV.
I perhaps shouldn't have said "bad," as my opinions sadly aren't universal truths ;)
However, my reasoning is the same as noted in echelon's reply. There are often far better ways to move around as described in ":h text-objects" and ":h motion.txt" more generally.
Ideally, you would never need to adjust motion by a random number of characters; you would use semantic motion by text object, making hjkl a rare corrective move. In practice, we are only humans, so...
for me, it is more like "40+ years of vi". vim is simply the best version of all of the vi-based editors that i have used, across many platforms. vim is brilliant (and i am very sad to hear of the author's death), but i think we really owe it all to bill joy.
Same for me: vi (later vim, later neovim) since the late 1970s. I used ed in the early days, too, and that may be why I love the fact that vi* lets me type ":" to do powerful things.
i had to teach a C programming course that used ed as the editor because i could not at the time get vi/ex to work because of terminfo/termcaps and other problems (which i later fixed). also bourne shell. students, who were on a basically business oriented IT course in about 1985 (?) never complained.
try inflicting something like that on people now, though it might be good for them.
Vim's addition of .vimrc and .vim allowing you to store editor programs to further accelerate your editing makes stand vim far beyond vi.
Credit Bill Joy for the modal editing paradigm, but vim is so much more than that. Most editors have a vi mode, but they don't compare to vim because they are awkward to script and don't have powerful regular expressions so readily available (both introduced in vim).
We could thank Ken Thompson and Dennis Ritchie for enabling vi, but I thank Bram for keeping vi viable, portable, and well-supported across languages.
The last 20 years don't mean anything; the Vim codebase is too much of a dumpster fire for anything significant to happen in that time span.
They had to fork an entire parallel command set to implement "location lists" (new in Vim 7, I think) which are exactly like the "quickfix list". Most of the difference are that location list commands start with l, wheras quickfix list commands start with c. Your keybinding to go to the next quickfix item doesn't work in a location list because it uses :cn^M, but the location list wants :ln^M or whatever. The only explanation for this ridiculous state of affairs must be that it was too difficult to extend quickfix lists to do the things that location lists do. Once you get into the Vim codebase, that will not be surprising.
Vim's visual editing semantics assumes that you have a block cursor, and that that the character covered by the cursor is included in a visual selection. This is not so nice when you switch your terminal to an I-beam (or vertical line) cursor, which references between characters. If the cursor is to the left of the selection start, it includes the character to the left of the cursor too. I-beam semantics allows for a zero-length selection, whereas in block semantics, there is always at least one character in the selection, which is the one under the cursor. I-beam semantics is virtually what pretty much all GUI editors do, including the text widget in Firefox I'm using now to type this.
A bunch of years ago I looked into what it would take to have a flag in Vim to flip to I-beam semantics for selection. Gack! I estimated a month of full time work. Numerous places in the code would have to change in ways where you're not sure what side effect they will have elsewhere.
> Your keybinding to go to the next quickfix item doesn't work in a location list because it uses :cn^M, but the location list wants :ln^M or whatever.
Navigating quickfix and location lists is global, so a single common command wouldn't make sense (you can use `:cn` from any window -- even if the quickfix is not visible). However, you could use a `<buffer>` map to use the same key to navigate within loclist/quickfire windows.
> The only explanation for this ridiculous state of affairs must be that it was too difficult to extend quickfix lists to do the things that location lists do.
Their entire concept is to be what quickfix isn't: instead of a global list, it's a list that's tied to a window. I can't think of features that a loclists have but quickfix doesn't unrelated to their nonglobal nature.
I can't claim vim's code is easy to understand, but this is not a fair complaint.
This seems like a good compromise. Also, say, the r command which replaces the character under the cursor could also switch to a block cursor momentarily. E.g.
a|b
Type r, and b gets covered by a block cursor. Then type c, and b is replaced by c, and cursor goes back to bar.
It's impressive to me how much Vim's development has continuously accelerated throughout the lifetime of the program so far. We might think of it as an 'old-fashioned' tool, but it has really flourished and grown a lot on the last several years.
80 comments
[ 3.3 ms ] story [ 170 ms ] threadVim was the first text editor I've ever used (back in 2008), and it shaped the way I interact with computers forever. I'm grateful to all maintainers, and to Bram for creating it and shepherding it through all these decades.
The annotations are interactive, so if you hover them you'll see more context about the events.
I built the tool to make this visualization: https://www.contextualize.ai
It would be helpful to put this somewhere on the page. On mobile especially one isn’t likely to accidentally discover this with random mouse movements.
How could anyone skip any other more "normal" editors and jump right into Vim?
Downloading something over limewire or torrent and seeing a readme file for the first time is a pretty strong memory.
My first IDE was visual studio writing Visual Basic, I quickly binned that for netbeans and Java and then I think ended up using Eclipse.
Today I’m a casual evil mode emacs user mostly for magit and org-mode. also working in VScode for web languages.
But, I also think there’s enough leeway in the idea of “using a tool” to not be surprised that somebody doesn’t count a one-off use of notepad. And I think there must exist at least some people who really never used notepad.
Nowadays I only assume someone between, like, 30 and 50 will inherently have to have used Windows at some point. Outside that range, you might get graybeards who were around before Windows, or younger folks who only ever used smartphones.
Anyway, all that rambling is to say, I’d put it in the “most but not shocking to hear otherwise” category.
What I’ve tried to express is that there’s a small band where not having used it is unusual and surprising, and that isn’t the case anymore. I still think the majority of people have used Windows at least a handful of times but hearing that somebody hasn’t no longer produces a “how could anyone” sort of response.
After trying out finger-twister with Emacs, vim was a breath of fresh air, and had better features than plain "vi", like it was improved or something.
Now, how do I save and exit?
gvim (for GTK/Gnome) is an official part of vim!
Sort by creation date, notepad, kedit, kwrite, notepad++, Scite, and plenty more.
For me it was my first editor on Linux. Didn't stick until I rediscovered it some 20 years ago when I got fed up with the netbeans nonsense and gedit and Kate kept breaking on me.
> This chart shows the last 20 years of development as seen in the Vim git repository.
https://en.m.wikipedia.org/wiki/Vi
nvi and vile were two names that spring to mind, but I know there were others.
Looks like vile itself started in 1992:
https://invisible-island.net/vile/
In what ways has vim become a completely new editor?
Personally, I've been using Vim for years, but I must confess that I use almost the same commands as I did in the beginning. Is there any good website that teaches useful tricks, maybe on a daily basis?
My own "trick" for improving my vim usage was to start mapping things to <Nop> that have better replacements, it is a great way to shock yourself out of bad habits like hjkl movements or reliance on /. Then again, I think text-objects and the items below it in motion.txt are the main to use vim so YMMV.
¹ http://vimcasts.org/
² https://pragprog.com/titles/dnvim2/practical-vim-second-edit...
³ https://pragprog.com/titles/modvim/modern-vim/
I got stuck in that suboptimal mode and had to break myself of it.
However, my reasoning is the same as noted in echelon's reply. There are often far better ways to move around as described in ":h text-objects" and ":h motion.txt" more generally.
https://github.com/takac/vim-hardtime
try inflicting something like that on people now, though it might be good for them.
Credit Bill Joy for the modal editing paradigm, but vim is so much more than that. Most editors have a vi mode, but they don't compare to vim because they are awkward to script and don't have powerful regular expressions so readily available (both introduced in vim).
We could thank Ken Thompson and Dennis Ritchie for enabling vi, but I thank Bram for keeping vi viable, portable, and well-supported across languages.
I've been using it for 29 years now.
The last 20 years don't mean anything; the Vim codebase is too much of a dumpster fire for anything significant to happen in that time span.
They had to fork an entire parallel command set to implement "location lists" (new in Vim 7, I think) which are exactly like the "quickfix list". Most of the difference are that location list commands start with l, wheras quickfix list commands start with c. Your keybinding to go to the next quickfix item doesn't work in a location list because it uses :cn^M, but the location list wants :ln^M or whatever. The only explanation for this ridiculous state of affairs must be that it was too difficult to extend quickfix lists to do the things that location lists do. Once you get into the Vim codebase, that will not be surprising.
Vim's visual editing semantics assumes that you have a block cursor, and that that the character covered by the cursor is included in a visual selection. This is not so nice when you switch your terminal to an I-beam (or vertical line) cursor, which references between characters. If the cursor is to the left of the selection start, it includes the character to the left of the cursor too. I-beam semantics allows for a zero-length selection, whereas in block semantics, there is always at least one character in the selection, which is the one under the cursor. I-beam semantics is virtually what pretty much all GUI editors do, including the text widget in Firefox I'm using now to type this.
A bunch of years ago I looked into what it would take to have a flag in Vim to flip to I-beam semantics for selection. Gack! I estimated a month of full time work. Numerous places in the code would have to change in ways where you're not sure what side effect they will have elsewhere.
Navigating quickfix and location lists is global, so a single common command wouldn't make sense (you can use `:cn` from any window -- even if the quickfix is not visible). However, you could use a `<buffer>` map to use the same key to navigate within loclist/quickfire windows.
> The only explanation for this ridiculous state of affairs must be that it was too difficult to extend quickfix lists to do the things that location lists do.
Their entire concept is to be what quickfix isn't: instead of a global list, it's a list that's tied to a window. I can't think of features that a loclists have but quickfix doesn't unrelated to their nonglobal nature.
I can't claim vim's code is easy to understand, but this is not a fair complaint.
let &t_SI = "\e[6 q" and
let &t_EI = "\e[2 q"
in some auto commands to sort of address this
If I tried running a version from 20+ years ago, today, would it still work on a modern O/S ? Are there modern vim features that I would miss?