I’ve been in the VI/Vim camp for a long long time. When I got started with Unix (I started out on HP-UX – but don’t worry Richard showed me Linux and I’ve never looked back.) you had two choices – VI and pico. Pico was a simple text editor. If memory serves it was developed to be the text editor with the pine email system. As a consequence, it had one feature that could make it a nightmare – it automatically wrapped lines. (as pointed out by Richard you can avoid this fate by remembering to add a -W. It didn’t help that for licensing reasons – there was/is no pico for Linux. They have nano now – but by the time that was standard I’d paid my dues) That’s pretty desirable for email, but terrible if you are writing code or a config file. I ended up learning the basics of VI.
I have a friend or two who swear by emacs. It was has always been on my list of things to spend a week really learning, but I’ve just never gotten there. The reason is simple. Every Linux box ships with Vim. It is right there waiting for you. (Ubuntu’s default is a little crippled but I’ll get to that). So if you end up modifying files on remote machines (which was once a regular thing for me) it is an essential skill.
If you are going to use Vim – there are a couple of things that I couldn’t survive without. Namely splitting and search & replace. Splitting is easy to explain – you are able to split the terminal in half (or less depending on how many things you keep open at once). You can even split the file you are in so you can look at two different parts of the same file. That ends up being pretty useful when you are dealing with code, or you are looking at a config file that should be similar to another block in the same file. Keyboard command is
If you need to switch between “windows” there are a bunch of ways (like everything else in Vim) but you can stick to Ctrl-W to rotate through them.
Several of the people I’ve worked with complained most about my constant opening files, splitting, making changes, and then closing files before they knew what files I was opening let alone what I was changing. Once you get the hang of it, it is awesome. Unless of course you are on an Ubuntu box that has vim-tiny. Vim-tiny doesn’t support splitting. It drives me insane and is the first thing I upgrade when I touch a box.
Which leads to other essential skill – search and replace. There are probably books written on this subject. I won’t repeat, but I will show you some things that I end up doing a lot.
%s/\(.*\)/mv \1 \1/g
That says for all lines (%s – s means a single line) take the contents of the line and replace it with mv (the contents of the line) (the contents of the line). I end up using this to build a shell script to rename files en mass. You can do more than this – but it gives you a taste. And if editing a single file isn’t enough you can do the old
vi `grep -rl pattern *'
:argdo %s/pattern/new_pattern/ge |update
That builds up a list of files recursively and throws it into Vim. Then the argdo lets you do a search and replace across all the files. You can do something similar with :args but I can never remember how to make it recursive.
Over the years I’ve programmed in a lot of different languages. I always seem to move on to the next one just as the tools for the one I’m in start to get good. So I’ve never really used an IDE (Integrated Developer Environment) as part of my work. I couldn’t afford them when I did C/C++. They didn’t exist for PHP or Python when I wrote in them. The Ruby on Rails community was completely dominated by Textmate (and the mac fanboyism that went with it). But since then things have improved a lot. There are even choices now. I originally got exposed to RubyMine when the developers on the team were starting to move away from Textmate. They seemed to like it. I didn’t think much of it since I had Vim. Then later when I was working as a developer on TruckingOffice in a pair, I got an ultimatum. I had to use a tool in common with the other developers or I wasn’t going to get to stay in the pit. I guess I split files one too many times. I reluctantly switched over to RubyMine. As time has passed, I’ve come to really like it. I have even been playing with the community edition of IntelliJ since I’m experimenting with Android development.
It has more features than I could shake a stick at, but there are two that have become essential to my sanity. The first is focus tests. You can point at a single example in a spec file and have it run. This saves me a bunch of time when I’m working on adding a feature or fixing a bug. At one point, I spent a week learning the internals of Vim enough that I could add a plugin to do the same thing. I got something to work, but it is no where near as elegant. Especially because of the other feature that I’m hooked on – debugging.
In the past, debugging to me meant adding printf/echo/puts to the file that was causing the problem. Rubymine has an excellent debugger integrated in. And if a test fails, you can easily add a break point and switch from running the spec to debugging it. Between RubyMine’s debugger and Chrome’s debugger, I’m left wondering how I programmed so long blindly.
I would love to say that now I do everything in RubyMine. I guess old habits die hard. I do all my coding, and testing there. I still end up with terminals running tasks (which I know RubyMine can do) and opening files from time to time in Vim because in some ways it is just how I think about it (even though RUbymine has enough keyboard shortcuts to satisfy a six armed man).
So if you are a system administrator – get learning Vim. Add a new command a day and in ten years you’ll have mastered it. If you are Ruby dev, I highly recommend RubyMine. I’ve resisted a lot of changes to how I develop, but this one is worth the learning curve.