Two decades of productivity: Vim's 20th anniversary | Hacker News Reader

Two decades of productivity: Vim's 20th anniversary

arstechnica.com

210 pointsevo_952 comments

My perspective may be skewed from not being an old-timer, but Vim seems like it's never been more alive.

So much of what I rely on in my Vim customizations is pretty new, and so many of those plugins are new themselves. The core of Vim is timeless (or, in Tim Pope's words, "Vim is forever"), but everything that I plug into it to make it the essential piece of software it is for me (including much of Mr. Pope's work) is very recent.

Definitely.

All of the "sync vim plugins from github" scripts + combined with Pathogen have made using and trying plugins much easier.

Github + better visibility have perhaps raised the overall quality of plugins by making it easier to copy and extend existing plugins.

I'm happy with the renewed interest and still learning new things in Vim all the time after 5-6 years of using it.

I wish there was a standard format for cheatsheets for vim plugins, I have many installed that I'm not using because I keep forgetting them. Ideally I could keep my current cheatsheet on a e-ink screen on the wall by my desk.

Strangely enough, Vim is part of the trendy Mac / Ruby / polished websites with exclamation mark and one button setup. That may explain this revival atmosphere. Why strange? Why, Mac setup is supposed to be beautiful and easy, Vim is neither.

Easy, no, beautiful? It can be. It can be very beautiful in its simplicity.

I like to think learning Vim akin to learning a musical instrument. It's not easy, the learning curve is very steep and it forces you to think about writing code in a completely different way. But once you get the hang of it, the power available to you is absolutely incredible and you'll code with efficiency never thought possible.

My 2 cents.

Sorry, but Vim is not beautiful nor "simple". It is, certainly, beautifully crafted, but this is another meaning of the word.

In fact, this reminds me French painter Braque being shown a fake Braque, he said: "this is not my work, it is beautiful". What I mean is that "beautiful" in the common sense, the one that applies to clothes, girls, gadgets (including Apple's), commercial movies, 3D games, etc., this superficial aesthetic quality not important.

In this sense, Vim, with it's fixed width font, black background, pure-text help, etc. is certainly not beautiful, and therefore a bit of a stranger on a Mac where, apparently, so much money and neuronal activity has been spent to beautify its OS, its casing, its font aliasing, every single icon and even its boxing.

Gosh, look at the Vim logo and tell me by which miracle it can have so much sex-appeal in a Mac environment? (Or has it? dasil003 says no in an uncle comment, maybe he is right.)

Again, I think you are missing the point.

Notice how I said it 'can be'. Out of the box, Vim is not very attractive, but with a bit of work it actually looks rather nice (yes, I did modify the application icon, but that's not really what I want to get at here).

Some of this beauty is subjective due to the syntax highlighting used, configuration of invisibles, etc, but that's configurable and therefore can be customized to your liking.

There are clean and elegant fixed with fonts, which again, you can choose whichever you prefer.

What I meant by simple was the complexity (or lack thereof) of the UI. It only shows you some basic information that is readily important, everything else is hidden away in various keyboard shortcuts. This makes it more complex to use, but it also means the beauty of your work, the code, is at the forefront with little distractions. Hell, I even turn off scrollbars.

At the risk of starting a discussion of opinions over my choice of syntax highlighting, here's a screenshot of my vim setup:

http://dl.dropbox.com/u/18782/macvim.png

I don't really understand how you can call this ugly, unless you're referring to my taste in syntax highlighting.

You can add all the make-up you wish on Vim's face, it will still be Vim, like your screenshot show plentifully. And Vim was not designed with aesthetics in mind. It is not the product of a designer or a "industrial design is kind" company. On the contrary, I would say. Vim is a very nice piece of software done by a hacker for mostly hackers, and the highest concern was probably extensibility, consistency of the commands, orthogonality, etc. (The doc was obviously a primary concern too.)

So, my first point still hold, where Textmate is a ease, Vim is a kind of an intruder in a Mac / Ruby / Designer-first set-up.

I don't see where Textmate and Vim differ in an aesthetic sense when it comes to working with the editor. The chrome on the two may differ, but when you use the same font and syntax highlighting colors, they are going to look the same

http://dl.dropbox.com/u/9380/VimVsTextmate.png

Are we talking about the same thing here? We are talking about a TEXT EDITOR. The INTENTION is to EDIT TEXT.

Vim does EXACTLY that. It doesn't add silly buttons that require you to remove your hands from the keyboard to the mouse to interact with. It doesn't add silly gradients that get in the way of showing you text. Aesthetically it's incredibly simple, and interactively it's incredibly complex, but IN A GOOD WAY. Not everything, especially tools, should be easy to use and learn. A well designed application knows its target and exploits it. Vim does exactly that. It doesn't mean it's a catch all tool for everyone, generally those kinds of tools end up half assed.

And for the record, I am actually a designer, I used to use TextMate, I now mostly use Vim. The UIs are similar in their sparseness. The 2 small beefs I have with Vim is the title bar text being overly verbose and and the rounded corners added by Lion on the bottom are rendered a bit glitchy.

TextMate on the other hand, while a decent text editor, has perhaps the most hideous project drawer around. Wait, actually, TextMate was never 'designed' as you describe it either. It just uses built using Mac OS libraries. I would think that if you were going to harp on design so much you would at least bring up the more 'designed' text editors, like Coda and Espresso, not TextMate.

Why does everyone say this? I found it fairly easy to learn the basics and intermediates of. Then again, I'm an Emacs guy, so maybe that plays in to it.

The built-in vimtutor taught me enough Vim to instantly make me more productive in Vim than a regular text editor. o, O, A, dd were such obvious time-savers that I had productivity gains off the bat, compelling to switch immediately and never look back.

I see what you mean, but as someone who uses OS X, Ruby and Vim as my primary development tools I don't think Vim is anywhere near a majority. Rather I think the Vim switchers are more numerous and vocal, inflating perception of our numbers.

In my case I probably never would have switched if TextMate 2 hadn't been extended vaporware. What it made me realize is that I'm fine using a commercial OS like OS X, or a trendy framework like Rails as long as it's suiting my needs in the short-term. But an editor is my core tool across time and space. I need it to be available on any platform, and be well-suited to any language I might learn in the future, working well over an SSH shell is also a huge bonus (and how I got my feet wet in vim 15 years ago). I appreciate aesthetics, but it doesn't trump pragmatism, and I think many rubyists feel the same way.

I think you're getting the marketing of Apple products mixed up with why OS X is part of this "trend".

OS X is popular among hackers because it's both a Unix-like and polished/supported enough to use as a "serious" workstation (not that Linux or *BSD can't make a decent desktop, but most would rather spend time writing code than config files).

It's really just about having an operating system that provides everything you need without having to worry about it, because as a programmer your time belongs with the applications. And when it comes to applications, you choose the right tool for the job (enter vim).

> most would rather spend time writing code than config files

That's why I use Ubuntu.

You can show your love for VIM by making a donation to help kids in Uganda: http://www.vim.org/sponsor/index.php

Personally, I love VIM (and I would quit my job if I were forced to use anything else), I made a donation a few years ago, it's time that I made another one.

And emacs sits here, in its mid-30s, looking forward to the pictures of vim's 21st birthday involving it passed out drunk on the front lawn at sublimetext's place.

(seriously, happy birthday vim, it wouldn't be nearly as fun of a holy war without you :) )

Yes, Emacs vs. Notepad would be a little lopsided.

This is vim's 20th birthday. Bill Joy's vi screen editor was written (based on ex) c. 1978 I believe. GNU emacs was begun in 1984, though of course "EMACS" has a much longer history going back to TECO on the PDP-10 in the early 70's.

Updated original comment to match.

I was actually wondering about that, something felt wrong about vi only being 20, but not enough to actually look it up. And yeah, I was using the '73-'74 TECO macros date for emacs.

I have typed more keystrokes into Vim than any other application in the last twenty years.

If I live to ninety and lose my mind, I will still be able to type in Vim.

You do not know how true that is. I used vi in the early 1980s for several years and then went to a job for a decade where I used another editor. Yet when I sat down in front of vim I still felt right at home. It's truly like riding a bicycle, you couldn't forget it if you tried.

The article misses the foundational reason Vim is still relevant. Observe:

  :help style-changes

  The basic steps to make changes to the code:
  1. Adjust the documentation. Doing this first gives you an impression of how
     your changes affect the user.
  ...

Are you blown away yet? The first step in hacking on vim is to hack on the docs. This has been true since the start. Many's the hour I've spent bouncing around in Vim's incredible docs, and I have no doubt it has encouraged more contribution from more hackers.

Emacs has something similar, to the extent that every (noteworthy) function added has its own documentation, which is exposed through a standard help feature.

Yeah, Visual C++ has that too.

I have always gotten a real kick out of the fact that a large % of the questions in #vim are answered by ":he $THING". The help system is so good that most of the rest of support[1] comes from those few things humans do well, like matching fuzzy concepts and questions to search terms.

[1] It can always be better, but the amount of time i spend searching random vim stuff outside the official documentation is trivial, particularly when compared against most other tools I use.

I have nothing productive to add to the discussion, other than that I love VIM, I've been using it since 1998, and I've never found any editor that makes me anywhere as happy as VIM does. I once had a job that required I use Eclipse IDE. I almost quit that job, but last minute, I found a VIM key-bindings plugin. Okay, not really, but it was very frustrating until I found that.

I actually did quit when I was (among other things) forced to use Eclipse.

Vim bindings are nice, but when I have to use an IDE, the one feature I want is the ability to make files open up in Vim for editing.

I'm OK with having an IDE window hiding behind my Vim window, to switch to for when I need to click on a Build button, or a built-in debugger to use on occasion. I just absolutely want to have my files open up in Vim when it's time to manipulate text.

This used to be possible in Xcode and it was taken away with Xcode 4. (I'm unaware of any workaround, though I will go hunting for one next time I am on an iOS project)

Yep, key bindings plugins are a poor substitute for Vim itself. Vim is more than keys.

I long ago gave up on any kind of Vim/vi plugin to anything. My first inclination, when I have to use a tool that wants to own the text, is to open Vim and the other, and figure out a way to re-load when I move to the other.

Eclim [http://eclim.org/] does this for Eclipse.

I love vim to bits, but can't believe that plugins are still such a mess. Why haven't they just rolled tpope's Pathogen into the standard vim distribution yet?

Have you tried Vundle? I found it about a week after I got into vim and it was pretty easy and accessible.

I havent tried Vundle, but looking at their github the search and installation stuff looks pretty cool. I'll probably stick with Pathogen though since it's already setup and working.

I just feel really bad for anyone who hasn't started using a plugin-manager with vim, and think it's crazy that this functionality isn't built in yet. Smooshing everything in together in ~/.vim was/is so archaic

What mess? Unpack tar, mv files to vim/plugin or vim/doc. Easy to do, easy to undo, works well with versioning.

Compare that to Pathogen:

  To install:
    1) untar/git-clone/whatever
    2) there is no 2.
  To uninstall:
    1) rm -Rf foo
    2) there is no 2.

I never tried pathogen, it is probably very useful but in the example you give I have no idea about where my plugin is plugged, so I don't know how to rm it if needed.

By default it uses ~/.vim/bundle/ Just drop directories into there to install and [re]move them to uninstall.

It really is a thing of beauty.

    let g:pathogen_disabled = []

makes an exclusion list to disable without actually removing a plugin.

Happy birthday to the best piece of software I use.

Isn't it a bit of a retcon to say that Vi(m) has grep builtin?

As far as I understand it, grep was named for the :g/.../p sequence one can do with Vi's global command; that is "global-regex-print".

"grep" came from ed: g/re/p "global regex print".

It's much older than vi (1976 vs 1973):

http://en.wikipedia.org/wiki/Grep

There's also :vimgrep

I believe it's more useful on Windows machines, which for some reason usually come without preinstalled grep.

Got a question for HN-ers. I would love to be able to use VIM as I would with Eclipse but perhaps maybe I should change my mindset to fit VIM not the other way around.

Here's the thing: I'd like to change my style of work from using Windows/OSX to using VM with Ubuntu server or some Linux without X installed (browser testing is done outside the VM, of course).

Some of the tools/tech I aim to use: PHP, Python(Django), Ruby(Rails), PostgreSQL(MySQL), JS, HTML, CSS, C, and maybe Java (once in a while).

Now, Eclipse has spoiled me a lot (like, really really a lot: 90% of my time is spent using keyboards and 10% on using the mouse. I know a lot of shortcuts to make me very productive navigating a large multi-projects enterprise Java app from XML[Maven,Spring], CSS, JSP, to JavaScript).

I can jump from JSP straight to the Java class if there's a Scriptlet there.

I can jump from Spring XML configuration to the implementation class and all with one key.

I can run JUnit tests easily without using mouse.

Refactor is a breeze.

I can add and dive into 3rd-party library code (let's say spring-core or even hibernate) easily via Maven + pom.xml (m2clipse plugin will download the 3rd-party library source code provided the jar exist in the repository as soon as you try to see the implementation code of 3rd-party library).

Pretty much doing everything almost without having to leave Eclipse.

These days, I want to try the other ecosystems (RoR, Django). How can I recreate such environment and workflow using VIM or Emacs (I don't mind learning other tools such as ctags).

Give me your input HN-ers! :)

Here's to twenty more years!

It's funny how times change. I remember the time when emacs came around and I stubbornly stuck to vi. Now I'm glad I did!

Speaking of line editors, anyone remember edlin for MS-DOS? Sometimes I think I hallucinated it.

Sure, back then it was the only editor available on an MS-DOS installation (was it 3.3 or 4.01?) to the poor soul needing to tweak his CONFIG.SYS and AUTOEXEC.BAT files.

EDLIN was the only text editor for all MS-DOS/PC-DOS versions prior to 5.0, when they were able to piggyback off QBASIC to create EDIT.

It was IBM's bastardization of ed, the standard text editor, and one of the best computer jokes:

http://www.gnu.org/fun/jokes/ed.msg.html

I think it was developed by SCP for 86-DOS.

I use VIM

Reply on news.ycombinator.com