Software Development

Checking out the Vim code editor

After hearing his peers swear by Vim, Justin James decided to take a look at the code editor. Find out if he thinks Vim is a viable option for his workload.

Vi is a keyboard-driven editor where the standard mode is to give commands, and things such as editing text are the results of those commands. The "insert" command puts the editor in a mode that resembles the normal input mode of a typical text editor.

I use vi on a regular basis, but I still only know five or six commands. So I decided to give vi's "improved sibling" called Vim a deeper look and investigate it for my code editing needs.

Four reasons why I tried Vim

  • A number of people whom I respect put a lot of stock into Vim as a code editor.
  • I find myself working on *Nix systems from time to time, where my normal apps are not available. Why force myself to keep going back to my desktop to make and change and then re-upload it when I could make the change directly on the system?
  • I've been exploring outside of the Microsoft ecosystem a lot lately. For instance, I recently got around to shifting all of my personal development from TFS to Mercurial, shutting down my TFS VM, and giving that RAM to another, more useful VM (I see a Kiln + FogBugz test in my future).
  • My recent experiments with IronRuby have left me less than thrilled with the Visual Studio experience, and I was curious to find out if Vim might be a better choice.

Installing Vim

I downloaded and installed the gVim package from the Vim website. The install package was small, and it went quick. It also offered to install a Visual Studio plugin, but I have not been able to see it in Visual Studio 2008 or 2010 since the installation, and the documentation has not been very clear on that topic. (Vim is free and open source, though the authors encourage you to make a donation to charity, which I chose to do.)

Learning about Vim

Vim is a very feature rich application; it's a text editor with enough meat to justify some books about it. In many ways, Vim reminds me of WordPerfect 5.1: It's an extremely powerful, keyboard driven editor that requires a fair amount of time and energy to leverage, but the effort is well worth it.

After learning a lot more about Vim by going through the tutorial (which walks you through the most common commands), I can see why folks who use the code editor on a regular basis swear by it. Vim is extremely powerful, if you take the time to learn it. Little details, such as knowing that you can apply commands to individual words or lines or multiples of such with a simple twist, go a long way to speeding things up.

Using Vim is different enough from other editing systems that you need to approach it with a different mindset. Until you really internalize the Vim way of doing things, you won't be as effective as possible. Vim appeals to people who figure out how to "min/max" every aspect of their day, but if that's not your style, you won't get much out of the code editor.

Reflecting on Vim's use for my work

I feel that Vim is of limited value for my particular workload. Vim would be an awesome tool if I were to return to the Perl days of my youth or shift my development work to Ruby (Figure A is a screenshot of gVim editing Ruby code). Figure A

Editing a simple Ruby program in gVim

Hand editing HTML and CSS would also go really well in Vim, especially with heavy use of its scripting system. In those languages, you generate a lot of text and don't need nearly as many libraries to get stuff done, depending upon your project.

In my Perl projects, the overwhelming majority of my work stuck to a handful of expressions. But in the C#/.NET world that makes up almost all of my work, IntelliSense is a mandatory item to explore the things you don't know (Visual Studio's awful new Help system makes it even more necessary). Losing IntelliSense is a huge hit to my productivity, simply because it's so difficult to get from Point A to Point B in the .NET world without encountering at least some namespaces you don't know intimately. Even worse, in C#/.NET, so much of the work is spent doing things that could be considered refactorings that it's best to use a tool that's really designed for the task at hand.

Conclusion

I'm definitely leaving Vim on my system, and the next time I work in Ruby, I plan on using it in lieu of Visual Studio. As you can see in the screenshot, Vim has no problem working with Ruby and giving it the syntax highlighting treatment.

At the very least, this experiment reminded me of something that continues to frustrate me with C#/.NET: I feel like I write very little code and spend most of my development time trying to push buttons on existing libraries or get the tools to generate 30 lines of skeleton code to place my two lines of real code inside.

J.Ja

About

Justin James is the Lead Architect for Conigent.

21 comments
richoH
richoH

Psst.. vim has omnicomplete, which is (in my subjective opinion) far superior to intellisense anyway, but definitely can help you in that regard.

spf13
spf13

Vim is a great editor out of the box, but it's true potential is unlocked through plugins. spf13-vim is a great distribution of VIM plugins, syntax files, snippets and more all hand selected and configured to work great together. It is a good starting point for anyone intending to use VIM for development. You'll replace your IDE in no time. Check it out at http://spf13.com/post/ultimate-vim-config

javabuddy
javabuddy

Is this article also applies to VI Editor , i have seen VI and VIM use to refer same thing but not sure though. Javin JAVA , TIBCO RV and FIX Protocol Tutorial

Reality-based
Reality-based

I've used vi and vim for a long time. I tried Emacs, didn't like it because 1) it was a memory hog (when memory was expensive) 2) Emacs required two handed editing 3) Emacs not installed by default on Unix systems, so its presence could not be relied upon. Yet you should try Emacs for completeness, many brilliant programmers swear by it. Once you get over the learning curve, you can use the vi/vim editor for any language, and for plain text tasks like simple shopping lists. You don't have to relearn editing for each new IDE - very helpful when you jump around between IDEs, languages, and OS platforms.

AnsuGisalas
AnsuGisalas

I use MS-Word for my work, because the CAT-software I use is a word macro plugin. What it does is, it segments the text of the source file, allowing me to adjust segment lengths, then makes an empty, target segment (which is marked to use target language spell checking), into which I can type my translation of the source segment, each is left in the file tagged as respectively source and target. It also creates a Translation Memory (TM) file to which it writes the correspondences between source and target, it uses fuzzy logic to compare them and then to autosuggest translations of similar phrases when they occur. After the translation is done, the whole translation can be recreated on the basis of the source, using only the TM. It can also plug into machine translation (MT) sites online, as well as word-powered MT, and it can take in glossaries (lists of source language terms and the pre-approved target language counterparts) which makes QA easier and faster. Finally, it can clean up the file, cutting out all the source segments and removing all it's own tags, creating a finished target-language text. It's not a tool that can make a translator out of anybody, but it increases productivity and straightens out the work procedures. It also creates a means to quickly translate a modification of the original source text, even with a different translator - the customer can simply provide the TM along with the new source version, and they can calculate more fairly how to price the job, based on an analysis of how much new text there is, and how much of that new text is how similar to text already in the TM. I wonder if vim can accommodate something like that...

Sterling chip Camden
Sterling chip Camden

... take a walk on the wild side! Of course, I prefer the console-based version of vim over gvim, but hey it's a start.

Reality-based
Reality-based

See http://www.vim.org/about.php. Originally, vim was an improvement over the standard Unix vi editor. Now, on many Linux systems, the vi command leads to a vim executable, so 'vi' is often effectively 'vim'.

Neon Samurai
Neon Samurai

It's a wiki style notes app. In the back end, it makes clean use of directories and text files. While looking into a bug I ended up working directly with the text files. This spoiled me as now I keep opening Zim and wanting to dd lines into prefered order not to mention how many times I've typed "jjjjjjjjjjjj" before correcting it and using arrow keys. I actually posted a feature request asking if they could easily add Vim basic key mappings into the editor window but no such luck. It'd mean mucking with KDE/Gnome key mappings not just having Zim include Vim as the editor window or similiar. But now this leads me to a new question. How hard would it be to replicate some of the Zim functions in Vim? I want to add a folder/file tree down the left of the window though being able to replicate Zim's hot-linking and such would be a big bonus. Either way, I've been stuck on Vim since I finally got over the initial learning curve. I may take the time to default Vim for my Windows text editing also.

Neon Samurai
Neon Samurai

As the comment above mentions, Vim has a very powerful scripting system. The best description I've actually read is that Vim is more an "editing language" than an editor. As you learn the grammar and vocabulary editing power expands; one is immediately able to create new "sentances" with each newly learned word or grammatical syntax. Example: I learn "cw" is the word for "change word".. it's removes the word and leaves you in edit mode to type the prefered word. I then learn that putting a number infront is the gramatical syntax for "this many times, do this" so "7cw" becomes "change the next seven words" (which happens to be the correct length for an IP address). More Example: "q" is the word for "quit" "w" is the word for "write or save file" "wq" is a sentance stating "write/save file then quit" "!" is the word for "just do it damnit" "wq!" is the snetance stating "write/save files then quick.. just do it, don't warn me about overwriting other files" "a" = "all" "wqa" = write/quick/all or "write/save all open files then quick" Feature lists literally fill books and that's without getting into pre-fab scripts other's have created like one which presents customizations for Bash script editing. I think the only real limitation your going to run into are GUI dependent functions; one might not be doing graphic layout with images and copy text. You may also miss object management like turning text rows into a ordered or unordered list object automatically adding new bullets on as you hit enter or supporting drag/drop the list around the document. In your case, you may require the CAT related plugin or related GUI dependent functions so you'd need to keep Word around for that. If the file contents are purely text script though, you may be able to write your CAT related scripts in VIM then just import them into the dependent system or runtime engine. I've no idea what your setup looks like or requires though so these points are just random thoughts.

Justin James
Justin James

It has a very full featured scripting system. J.Ja

Justin James
Justin James

... I'll be turning the spare PC I have sitting around into a desktop FreeBSD machine setup like you have, minimal GUI-ness to it. :) J.Ja

Sterling chip Camden
Sterling chip Camden

Yeah, the one downside to using vi/vim as your usual editor is that it becomes difficult to use other editors intuitively. Back in the early days when a vi equivalent wasn't available on non-Unix platforms, I'd frequently find myself adding j's to source code. The other problem was that back in the 80's most business applications were written in all upper-case, so a lot of developers left Caps Lock on. I don't know how many times I hopped into an emergency vi session and joined half the lines of the file before I realized what I'd done. Those old vi implementations only had one level of undo, so the only sane option was :q! and try again.

Sterling chip Camden
Sterling chip Camden

You can actually write scripts for vim in ruby, python, or perl (if those options are compiled in). The sky's the limit.

Neon Samurai
Neon Samurai

"write/save all open files then quick" should have been "write/save all open files then quit" For some reason I can post original comments without disabling noscript but I can't edit my own posted comment without disabling noscript? Why such a difference between the two functions? (Again I'm left wondering "TR what did you do to this thing?")

Sterling chip Camden
Sterling chip Camden

I actually have a fair bit of GUIness available on my FreeBSD system. I'm almost always in Xorg (although I like the minimal XMonad window manager), and I use Firefox as my browser (with Vimperator). I just prefer text-oriented interfaces for text-oriented activities, like programming and writing.

Sterling chip Camden
Sterling chip Camden

... which only writes the file if changed. Re: keyboards -- I can't even survive on those ergonomic keyboards. I'm not a home-row typist, so moving the keys even a few millimeters from where I expect them causes me trouble. I guess one day I'll have to take the time to learn home-row.

Brainstorms
Brainstorms

You'd like this, Neon: Seems as though not many people know that you can abbreviate ":wq!" with "ZZ" -- much faster & easier to type! Here's a nice challege to keep your brain agile: Try using VIM with a Dvorak key mapping! (And when you've gotten that down, work with a collection of group machines, some of which are QWERTY only, and change seats throughout the day. Now I think I know what it's like to be bi-lingual... :^)

Sterling chip Camden
Sterling chip Camden

Your directory editing example might be achievable with a little scripting.

Neon Samurai
Neon Samurai

I used to complain about leaving the keyboard to reach for the mouse; strain on the arm, time/efficiency lost in movement with the mouse so far outside the keyboard area. I'm starting to feel the same way about the arrow keys; "ah man.. I have to stop what I'm doing and reach all the way over there just to move the cursor?". It's not to the point where I'm ready to change my standard game control mappings from number pad to "h,j,k,l" though. I actually started with Emacs before Vim but was turned off quickly by it's constant use of control+something commands and usually being two layers of control+comething deep for what I wanted to do. "Quiting is crtl+a then crtl+g? I'm outa here... Next!" What I did really like about Emacs was it's ability to "open" a directory and rename files/directories with a simple search/replace function just like when working with standard text. I'd love to be able to "open" a directory in Vim and :%s/filenamed.txt/filenamec.txt/g Otherwise, Vim is far exceeding my own limits; I know it can do more.. I just don't problems to throw those solutions at yet. :D

Brainstorms
Brainstorms

for syntax highlighting... Don't forget Tcl/Tk! :^)

Justin James
Justin James

Other than the MB's of XML configuration trash behind the scenes, it seems like most devs don't actually create much text... ;) J.Ja