VI is a key text editing tool available on unix systems. The most common version of vi used by desktop linux distributions is VIM. There are a number of implementations of the modal vi editor but I have learned and use the most common one, VIM.
Having a consistent and capable editor available on any system is important, especially important for people who move from machine to machine for whatever reason. People who administer UNIX systems or who help others with their operating system (like many Linux User Group members) need to edit files quickly. The family of editors known as vi (including nvi, aka. vi on BSD) is very useful for this. Some of the reasons for its success are the use of classic UNIX philosophy, regular expressions, keyboard use (no mouse required) and plugins. The learning curve is a bit steep for beginners. Because text editors are written for use in terminals they can be used even across platforms with the help of fink (brew and others) on Mac OSX and cygwin on Windows. Text editors are clearly not WYSIWYG word processors.
I like vim and I am biased. I’ve answered questions in #vim on Freenode. I’ve customized my installation with a personalized color scheme. I’ve written functions for use in my statusline. I use set ruler number hlsearch laststatus=2 cmdheight=3 and syntax on. I’ve googled and read other people’s vimrc files more than once. Over the years I’ve cobbled together configurations across many different machines. I’ve typed the vim command :help a lot. I’ve installed and used quite a few vimscript plugins and am still pleasantly surprised to find a new one that suits my needs well as my needs change. I’ve experimented with more modern ways to install plugins using git revision control rather than the traditional way of putting downloaded copies of files into a $HOME/.vim directory. I’ve written a little vimscript. I’ve played a couple games inside vim. I’ve tried my best to teach vim to a number of people in person.
The commands used for editing with vi and vim can come up in the most interesting places. The wikipedia article covers the history well. There are quite a few references to our home, Berkeley. A small version of vi is included with Cisco products. Perhaps we might be able to find some UC Berkeley and O’Reilly sponsorship to develop a vi* unconference style celebration in 2016 as vi/ex turns 40 years old!
What’s the best way to get started with vim? vimtutor is a great self-paced tutorial experience. Firing up vim and typing :help will provide you with the online documentation and instructions. Much has been written and said about vi and vim elsewhere. Mike Saunders of Linux Voice produced a great 12 minute video Learn to love Vim. It was featured on the front page of Linux Voice and encouraged me to write this article. The cheat sheet he referenced is fantastic. The related youtube videos also look interesting. Time and patience are really all that’s needed though these things seem to be in shorter supply than they used to be. While there is a learning curve it is worth it. Two friends, Michael and Jim, have both taught vi professionally.
A number of books are available notably from O’Reilly, New Rider, Packt and Pragmatic Bookshelf. At least one has a PDF download available. Purchasing from that page provides donations to Bram Molenar’s favorite charity, the ICCF-Holland which helps needy children in Uganda. Having seen firsthand some needy children in Kenya I encourage and support the works of ICCF-Holland.
This article should in no way be interpreted as a negative statement about other editors of any kind. gedit, nano, elvis, BusyBox’s clone and nvi are other common text editors. I am focusing here on text editing, not other differentiated text needs such as word processing. There are many good editors, most with highly specialized features for particular uses and/or for particular environments. Yet few other editors can be so well customized and are as universally available as vim. Code focused integrated development environments (IDE) also need to edit text and have many helpful features to write code. After scratching the surface I found that many features can be added to vim with some effort.
While emacs is powerful and comes to mind, emacs is not as universally available. While I learned some of the basics of emacs over the years and spent a period of time learning emacs many moons ago, I am not an expert. I realize that the emacs approach of not using editing modes (modes are used by vim) has advantages. Are you an emacs user? We welcome your blog post submissions.
I hope this article sparks informed discussion. Believe it or not, the choice of text editor has been known to elicit long discussions in some circles though this is far less prevalent now. People who work with text editors know that the choice of an editor can dramatically affect efficiency. Informed comments are encouraged.
We meet at Bobby G’s Pizzeria on the second and fourth Sundays of each month from Noon to 3PM in Berkeley near the Downtown Berkeley BART station. Bobby G’s is very close to the corner of University & Shattuck. We hope you join us, join the discussion on our email list and/or join us in #berkeleylug on freenode.net by following the tabs at the top.
Hi, thanks for the cheat sheet link. However, in my opinion, VIM is awful and unnatural. Its popularity is undeserved. There must be a way to make a text editor to work with edit and cmd mode in the same screen, this could even be sensitive to the mouse. Keyboards nowaday have Ctrl, Alt, Fx, Super keys. Ctrl-S to save text is much simpler than I don’t know how many keystrokes in VIM. End to go end of line, Ctrl-End to go end of documents. Shift = Nav keys = select text. VIM users will salive with envy if ever they knew such simple commands exist without resorting to that : command mode and go back to edit mode. The only reason VIM survive that long is b/c too many people just hang on that prehistoric text editor. No Dev tools, programing IDE, Web interface (for example replying to this blog), use VI edit/navigation style. Because it is inefficient and un-intuitive.
I find vim quite annoying … but probably mostly for different reasons.
http://www.rawbw.com/~mp/linux/vim/vim_annoyances.txt
nvi(1) – which is the vi(1) on BSD, is excellent.
Also, as I oft tell folks when introducing them to vi(1), vi is optimized for use, not learning. So there is a learning curve. But it’s highly worth it.
vi is like playing a piano – I cannot even explain what keys I use to someone who does not know the commands – it is the melody of the text which is my concern. A mouse and a GUI just have no rhythm 😉
The Good, The Bad and The Ugly — well, not really all THAT Ugly.
Most of The Good is in what grantbow wrote above.
IMO, another of my Good’s is that the installed VIM binaries (executable files) take up less diskspace than the corresponding command-line form of Emacs;’emacs23-nox’. AAMOF, the installed VIM binaries on my systems take up ~2MB diskpace as opposed to the ~6MB that ’emacs23-nox’ takes up. That’s especially good for the smaller-type Linux liveCDs when someone should need a more powerful and advanced trim ‘n slim command-line text editor alternative to Emacs or to an Emacs-takeoff like Zile or Jove, see http://www.emacswiki.org/emacs/EmacsImplementations.
A miniGood is that William E. Shotts, Jr., has an excellent and dedicated chapter in his book The Linux Command Line — http://www.linuxcommand.org/tlcl.php — that provides “A “Gentle Introduction to vi”. Chapter 12 of Shotts’ TLCL is only about 20 pages, and it puts the appropriate emphasis on designating VIM for the book’s eventual coverage of writing advanced shell scripts. Using VIM as Shotts suggests, I myself regularly and easily create a vi–>vim alias into my $HOME directories’ .bashrc for all my new installations; as alias vi=’/usr/bin/vim’. Super simple.
Now for some of The Bad and The not-so-Ugly.
Bad#1, as Innocent Bystander writes, is that VIM is somewhat “un-intuitive”. IMNSHO, its use of modes creates a significant degree of confusion for those not used to un-naturally switching back-and-forth between such modes and using the typical key commands in Command Mode. Even with all of VIM’s many benefits, there are better, more intuitive text editors than VIM. A command-line editor replacement for VIM that I previously mentioned on the mailing-list is the humble Nano, see http://www.nano-editor.org. While certainly not as versatile/powerful/whatever-else as is Vi IMproved, Nano has a ridiculously easy learning curve for newbies and IMNSHO it adheres to the KISS principle better than does VIM; see http://whatis.techtarget.com/definition/KISS-Principle-Keep-It-Simple-Stupid. And as for Linux GUI users (X windows), gEdit and Geany are miles better and simpler than the graphical version of VIM, gVIM.
Bad#2 directly related to Bad#1 is that, IMHO, VIM is now considered an Advanced Editor just as Emacs is. In other words, I doubt that it should be considered as the indisputably best and first text editor to start off with for Linux newbies. AAMOF, I posted back in March of this year, a post entitled ‘Massive Open Online Course ‘Introduction to Linux’ for Newbies’, http://www.berkeleylug.com/?p=1466 . This edX LFS101x MOOC — rolled out to the public within the last month or so — clearly lists Vi (including VIM) as an Advanced Editor along with Emacs, within its tenth chapter on Text Editors. Just as above, Nano again turns out to be the better Basic Editor for the command-line than is VIM. YMMV.
A miniBad#3 and possible future miniUgly I am keeping tabs on is whether VIM may be succumbing to featuritis, a.k.a., “feature creep”. Many of those benefits grantbow and others ascribe to VIM require going through tutorials to conquer the learning-curve for effectively using more and more of VIM’s features and increasing the complexity of its ~/.vimrc configuration file. Perhaps sometime in the not-so-distant future, VIM will even start including all the extra bells and whistles that Emacs now includes? I hope not, but still….
As an aside, I see that a possible acquiantance of grantbow(?) posted this Vi IMproved article to the general Linuxers blog, http://lxer.com. Great for those interested in following potential comments on VIM and maybe contributing their own further ideas on the subject. Anyhow, that’s all for now.
I am an Emacs user. It is not my place to criticize Vi or Vim, since I can scarcely remember how to enter text and save a file using Vi. I will comment briefly on Emacs. In my humble opinion, Vi would make a fine script or one-off, or configuration editor. I use nano, because it’s intuitive, and simple. I have also used zile, some of the MicroEmacs variants, Jed and Jove.
Emacs takes long to load, one reason a server-client architecture exists. I use Emacs for everything, but I still stumble about the need to start up several interations, or to use a client. The client starts up instantly, though.
Vi uses Modes? I think Emacs may have invented them?! One of the beauties of Emacs. Org-mode is the mother of all modes, I guess, and Vi adherents have even written their own Vi port. Not to get off track.
Most important, Richard Stallman was the original author of Emacs. He refers to it, appropriately, as “The Extensible, Customizable, Self-Documenting Display Editor.” That about describes it, for me. Vi is something I could fire up in a few milliseconds and edit a config file, if I had taken the time to learn the obfuscated command set. Emacs is a lisp interpreter that allows me to write little one-liners to perform various actions—for example on text—and assign them to keys. I have written a few such little utilities. What originally did it for me were the Tutorial—the best I have ever seen—and the incredible manual, accessible at the touch of a key, for which, I think, the TexInfo system was developed.
Why would anyone start a holy war about that?
Ah, one of the things I’ve started saying in more recent years of vi(1) (and vim(1)) – even though it’s been true for a very very long time (probably all the way back to the very early days of vi(1):
vi(1) is optimized for using it, not learning it.
So yes, does have fair bit of a learning curve – particularly compared to many other editors.
However, once reasonably well learned, it is very highly well optimized for being very well, efficiently, and easily used, and that probably also goes approximately double or more for use in a Unix or Unix-like environment, including Linux, BSD, POSIX, Cygwin, etc., as in such environments, there’s not only also a fair bit that can be leveraged from such environments (not only is vi(1) quite Unix like in its philosophy – one tool that well does what it does, and well connects to other tools – as opposed to one tool that attempts to do “everything” and may not connect so well) – so vi(1) very well connects to and can also use the tools in its environment, but in addition to that, there is much commonality and overlap – so if one learns vi(1) well, one also knows a fair bit of Unix, etc., or vice versa. Notably overlapping in areas of Regular Expressions, having fair bit in common with other Unix and similar editors (notably ed(1), and also ex(1), the latter actually being not a separate program, but a different mode of vi(1)), and much of the movement used in vi(1) is commonly used in other Unix/Linux/etc. programs, and even vi(1)-like editing is often used or available in other Unix/Linux programs, e.g. the bash(1) shell, and also ksh(1) (Korn) shells and similar.
And yes, I’m a wee bit biased too. I really really like nvi(1) – which is (the) vi(1) on BSD. And, well, vim(1) tends to annoy me a bit:
http://www.rawbw.com/~mp/linux/vim/vim_annoyances.txt