Happy Birthday Vim, The Venerable Text Editor Turns 20(webmonkey.com)
webmonkey.com
Happy Birthday Vim, The Venerable Text Editor Turns 20
http://www.webmonkey.com/2011/11/happy-birthday-vim-the-venerable-text-editor-turns-20/
11 comments
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."
"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."
Quite so. One quibble: ex is Bill Joy's reimplementation of ed. I think it was always intended to be part of vi.
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?
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.
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.
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.
This would be great. I have to use Excel every day at work and it's pretty annoying that 36+ keys of the keyboard basically just enter insert mode.
A solid, trustworthy vimperator-style plugin for Excel would be amazing.
A solid, trustworthy vimperator-style plugin for Excel would be amazing.
Emacs has evil-mode: https://gitorious.org/evil/pages/Home
I find it great for focusing on the power that M-X brings.
I find it great for focusing on the power that M-X brings.
You can have Vi keybindings in many popular editors / IDEs. There are plugins/settings for:
Your plugins, macros and settings though... it's tough to have those follow you around.
* Eclipse
* IntelliJ
* NetBeans
* Komodo Edit / IDE
* Visual Studio
Your plugins, macros and settings though... it's tough to have those follow you around.
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.
I'm still not sold on modal editing. Please sell it to me.
Stuff I can think of off the top of my head:
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
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
> It works especially well if you remap Caps to Escape.
And Emacs users remap Caps to Ctrl. Nobody really likes Caps, it seems.
And Emacs users remap Caps to Ctrl. Nobody really likes Caps, it seems.
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!
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!
Sql is case insensitive isn't it?
yeah, but for various (historical) reasons people like to DO IT ALL IN UPPERCASE TO DISTINGUISH LANGUAGE SYNTAX FROM "actual data".
As usual, computer science is an embarrassment for the computer.
As usual, computer science is an embarrassment for the computer.
Just look at the trade-offs:
- 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.
- 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.
You don't get sold on knowing on an intellectual level what it is. You get sold on it by using it.
I'm just in the middle of the learning curve and was wondering if I was missing something.
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.
http://www.viemu.com/a-why-vi-vim.html
And remap Caps Lock as Escape.
And remap Caps Lock as Escape.
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.
August 15, 2010 7.3 Lua support, Python3 support, Blowfish encryption, persistent undo/redo
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 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.
August 15, 2010 7.3 Lua support, Python3 support, Blowfish encryption, persistent undo/redo
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.
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.
Thanks for the reminder! This is something I've had at the back of my mind for the 10+ years I've been using vim, so high time.
Larger discussion here: http://news.ycombinator.com/item?id=3187065
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.
I think it'll always amaze that we haven't been able to do better tools than the goold old ones (Vim, Emac & Unix tools I'm looking at you).
Well... vim and emacs both grow with their users, and have acquired a lot of functionality over the years.
I'm still trying to get my head around the Plan9 utilities :)
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.)
Wow, VIM is just months older than I. Had the impression it was much younger.
I honestly don't know where I would be without vim. Happy Birthday!
"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."