"It isn't really Vim's 20th birthday. It's a lot closer to its 35th!" Because of course, vim is really just an extended and improved version of the venerable vi, the first screen-oriented editor for Unix.
While the article starts out with a history of vi, it somehow treats it as if it were a grandparent, rather than the template for what remains. The core design of vim reflects the design insights of Bill Joy, not those of Bram Moolenaar, who refined and updated them."
Well, I like this counterpoint too from the Google+ discussion:
"Sedat Kapanoglu: Technical innovation process on computing is too organic to find a single originator. Everything is derived from something else and that's what computing industry owes it's amazing progress in such a short term. Unix was from Multics. C was from B which was from BCPL. , and vi was from ex. We can consider vi itself as vim for ex from that perspective. I think there are no distinct thought processes for creating and improving. All creation is improvement and all improvement is a creation. We don't need to have a moment of silence for the father on a kid's birthday. Let the kid enjoy the day."
I had almost forgotten that Bill Joy, the creator of vi is also the co-founder of Sun; and Gosling, the father of Java authored his own version of Emacs.
Isn't it ironic that most people find Java, one of the major accomplishments of Sun, is almost impossible to code in vim or emacs without an IDE though?
Vim has the kind of user lock-in mechanism that big corporations can only dream of: modal editing.
Once you get sold on modal text editing it becomes very difficult to accept or use any other editor that doesn't do it (which is pretty much every other text editor out there). Sublime, Textmate, e - all great editors. Don't feel like using any of them after 10 years of Vim.
Another vim user and I were discussing this and I came up with the nutty idea of creating a 'vimspec' that detailed the basic features and extensibility a 'vim-mode' plugin in another environment would need to have to be useful to regular vim users.
I think most people developing 'vim-mode' plugins for other environments aren't necessarily vim power users so won't be aware of how natural normal mode is to regular vimmers (and importantly, what features you will miss).
Some sort of vim standard for normal mode might go a way towards making normal mode with its commands a more ubiquitous interface for editing text.
vi keybindings don't really suffice, though, even when fully implemented (which many tools don't). I don't just want basic text editing functionality, though vim does that extraordinarily well. I want substitution, compilation/quickfix mode, grep, indentation, abbreviations, file modes, highlighting, and a dozen other things that prove hard to enumerate until my fingers automatically use them and they don't work.
It's a good step forward though. For years, I was always torn about IDEs, it's very handy to be able to do so much automatically rather than having to do everything yourself. So much so that the productivity boost is near-required in a modern environment. But.. you don't get to edit in vi. For no particular reason as such, the editing scheme in the IDE is no less arbitrary. The whole kit would be nice, but hey, if it's at least modal and support the normal keyboard functions (around what you'd get if you just ssh:ed into your buddies box to help him with something and ended up editing things with vi, the local version, nothing customized) that's a lot.
It's easier on the fingers. You can move around using jkl, perform clipboard operations,deletions and other text operations generally without having your fingers leave the main keyboard area to reach for the modifier keys or arrows.
It works especially well if you remap Caps to Escape.
It's logical: dd deletes a line. 10dd deletes 10 lines.
f+ moves the cursor to forward to the next '+' character on the line.
2f+ does it twice - moves the cursor to the second '+' on the line.
df+ delete from the current position to the first + character.
Commands are chainable:
d2f+ deletes from the current position to the second '+' on the line.
In general when you have modal UIs (not specific to text editing) it makes it easier to accomplish work as you're working in a 'mode' that is specific to your task. When in insert-mode, your keyboard is used to insert text. In editing-mode[1] your keyboard's functionality is now used for the sole purpose of making edits and manipulating existing text. In visual-mode, the keys provide functionality to easily highlight and manipulate highlighted text.
That said - modal editing does have its drawbacks. There's a higher learning curve. And the lock-in thing I mentioned isn't necessarily a good thing. Non-modal editors can reasonably emulate each other's keybindings allowing you to easily shift between, say, Sublime and Textmate and Visual Studio. But good luck doing any of that with Vim thrown in. Also, Vim users have to still learn a reasonable amount of emacs keybindings in order to efficiently use the command line and native text fields on Linux/MacOSX.
Also as someone joked recently - Vim has 2 modes:
1) Beep at me
2) Destroy all my text
[1] not actually called that but that's how I like to think of it
No surprise there, it's just a legacy from typewriters after all.
These days, unless you're doing data-entry or a lot of SQL, caps-lock is just wasting (a lot of) prime keyboard real estate -- on the home row, no less!
- With non-modal editing, you get precise control of what's happening for every character that you type. In some ways, that kind of granularity is powerful. But what's the cost of that fine-grained control? The cost is having to be explicit about anything "special" you do in an editor with the letter keys. (Namely, you indicate that you're doing something special with the control key.) Imagine having to type capitalized SQL statements in a true non-modal way (i.e., without CAPS LOCK).
- With modal editing, you type in terms of ideas. You insert text when that's appropriate. When it's not appropriate, your entire keyboard (and every combination of keys) is free to do what an editor is actually supposed to do: edit.
Consider that you spend more time reading, navigating and manipulating code than you do actually writing it. For that reason, it makes sense to assign navigation and manipulation semantics to the keys on your keyboard. But, then you have to have two different modes of operation for the keys.
Bah.. stagnation is not worthy of being called life.
I love vim because it is the best. I can't use anything else because nothing else works like it.
I hate vim because it has stopped advancing. It has not had a good update for 5 years.
May 7, 2006 7.0 Spell checking, code completion, tab pages (multiple viewports/window layouts), current line and column highlighting, undo branches, and more
May 12, 2007 7.1 Bug fixes, new syntax and runtime files, etc.
August 9, 2008 7.2 Floating point support in scripts, refactored screen drawing code, bug fixes, new syntax files, etc.
We are all still waiting for various types of extensibility, even though they been in the top 5 sponsored requests for over almost 15 years. I normally wouldn't be complaining about free software, but vim is donationware.
> I hate vim because it has stopped advancing. It has not had a good update for 5 years.
Vim itself has stopped advancing, but there is an active community developing very useful and novel plugins. This has happened thanks to several plugin management systems that have arisen independently during the last couple of years.
If you appreciate Vim and use it every day, make a donation to http://iccf-holland.org/ - for many of us, Vim is an indispensable tool, if we all paid ICCF what we properly owe Bram for his years of Vim work, it would make a huge difference to people who really need it.
As someone more than twice that old, I find it amusing when something twenty years old is described as "venerable." The world of computer technology has seen many fashions come and go, but some tools have been comparatively long-lasting, and have been used through several generations of the newest and greatest other technologies.
So very few, though. Many standards have lasted that long (deflate compression immediately came to mind), but few specific tools have. The Linux kernel turned 20 recently. X has lasted 27 years, and remained backward-compatible (X11) for 24 years. GCC (24 years), Vim (20), and Emacs (35) have grown ever-more widely used. How many other specific tools that we use today have that kind of history?
Despite its age, I still find myself discovering new useful functionality. Reading this article, I noticed that the screenshot had a shell running in a buffer, which vim doesn't normally do. I searched for the text in the status line, and found ConqueTerm.
Nice article, but it kinda butt against chrome, which I like to upgrade every single time it come out. (Actually, it get upgraded automatically when I tell archlinux to update against itself.)
"It isn't really Vim's 20th birthday. It's a lot closer to its 35th!" Because of course, vim is really just an extended and improved version of the venerable vi, the first screen-oriented editor for Unix.
While the article starts out with a history of vi, it somehow treats it as if it were a grandparent, rather than the template for what remains. The core design of vim reflects the design insights of Bill Joy, not those of Bram Moolenaar, who refined and updated them."