Related
I am a quite happy user of Eclipse (I mostly develop in PHP and Python), however I found the answers to "What specific productivity gains does Vim/Emacs provide over GUI text editors?" interesting enough to make me wish to try out Vim or Emacs as well and see if they would turn out to be a better solution for me.
I have the general feeling that Vim and Emacs are not the kind of editor you learn by "playing with it" though. I have the impression you must dedicate some time and effort to "study" them a bit, before you can benefit from their power.
So, I have two questions for the community:
In the linked thread responders have essentially answered by commenting on Vim (often mentioning: "I'm sure Emacs has the same"). Google trends seems to indicate Vim is the mostly adopted between the two, however my first question is: knowing that I have no prior experience whatsoever on any of the two, and that I use and develop (mostly PHP and Python) on GNU/Linux systems (Ubuntu, Arch Linux), is there any of the two which would represent a better option to start with? (To be clear: my question is not about the quality of the editors but it is about what it is strategically better to learn in my situation).
What advice would you give me on how to learn using it/them? I know this is a broad question, but it is deliberately so. Have a look at this answer (unrelated topic) for an idea of the kind of information / style of answer I am looking for [but do not feel obliged to answer that way... any contribution will be welcome, in any form!]
EDIT (on picking the "accepted answer")
I picked one answer as the accepted one just now, but I would like to say "thank you" to all those who shared their experience and advice: almost all of it has being useful to me in some way. The thread has definitively exceeded my expectations! Thank you! :)
I would advise that checking out both is worth the time because of various reasons already covered by other answers or "Emacs vs vim vs XY" threads.
Still if you would have to pick one of them I'd go with vim because of one thing:
Availability
Vi(m) has the advantage that it is installed (not only available) by default on almost any *nix system. So no matter whether it is your system or someone else's or whether you are allowed to make changes to it or not, your favorite text editor and friend is there waiting for you.
Once you know vi(m) it feels awesome in those situations where you ssh into a machine and need to do something with text (navigating through a file, editing, whatever). You are going to feel like a King. I remember several times when I almost freaked out because nano or pico were not installed and I had to use "this ugly beast vi" which made unpredictable things when I started typing (because I wasn't in insert mode and didn't even know what that was) and when I was happy to have googled that ":wq!" gets me back out of hell. Now I can look back and smile about it.
I have the general feeling that vim
and emacs are not the kind of editor
you learn by "playing with it" though
Vim and Emacs are certainly editors that you "learn by doing".
Of course the question cries for including these highly scientific text editor learning curve graphs =)
Vim might be a bit harder in the beginning because its modal editing can feel quite unfamiliar at first. I think motivation is the key here. The article "Why, oh WHY, do those #?#! nutheads use vi?" explains the advantages quite well I think. In my opinion it really is worth to give it a try even while the learning curve might be steeper than with other editors and it sounds like you bring the necessary motivation.
Back to learning by doing.
Something I wish I would have done the first time:
Check out Vimtutor. It is an interactive tutorial which demonstrates the power of vim by showcasing it's basic commands and how they can be composed. Just type vimtutor in your terminal.
This helped me to really "get it" after trying to learn editing with vim several times in the past. The tutorial eases the learning curve dramatically as it explains the commands and makes you actually perform them so they become a habit. It really makes a difference compared to being frustrated because of feeling handicapped. Using vimtutor you also will see what the benefits of modal editing are and instead of fighting or ignoring it you are going to embrace it because you have experienced the advantages at first hand. I guess it would be pretty difficult to learn that all by oneself. So these 30 minutes are quite worth it.
I have the general feeling that vim and emacs are not the kind of editor you learn by "playing with it" though.
My experience with emacs is actually quite the opposite. I tried going through the tutorial, but it didn't seem to help much. The way I ultimately ended up learning is with a reference card and just forced myself to use emacs on my code until I got it correct*. Then again, I do also have a screw loose. Your milage may vary. Offer void where prohibited. You get the idea.
One other piece of advice I recall reading somewhere is to try writing down a list of about 10 commands you want to learn and keep it by you while coding. Once you've mastered those commands, make another list of 10 more. Keep doing this until you've got a big enough chunk of the editor committed to memory.
*Note that the linked reference card is out-of-date. If you google, you can get a more up-to-date reference card.
knowing that I have no prior
experience whatsoever on any of the
two, and that I use and develop
(mostly PHP and Python) on GNU/linux
systems (ubuntu, archlinux), is there
any of the two which would represent a
better option to start with?
I'm an emacs guy, so my opinion should be obvious. That said, you're likely best trying out the one that more people you know seem to use. Having someone who's experienced with emacs (and I'd assume vim) is a great help.
If you don't know anyone who uses either one, choose whichever one you feel is the prettiest or has the coolest name. You won't know enough to know which one you'll like, so you might as well choose arbitrarily.
For vim try vimtutor
I came to Vim when I started using Linux after years of Windows development, and had to do a lot of work on remote systems via ssh. For the first couple of weeks hated it. After that I could not live without it.
Probably the best way to start is to use Vim in easy mode ([g]vim -y), most installations have a shortcut called evim. This runs vim in a mode that is in insert mode by default and remaps keys to the usual Windows ones (ctrl-S to save, ctrl-X to cut etc). You can then use it like a regular Windowsy editor but still access the power of Vim.
There is also Cream which is Vim + a bunch of scripts to make it behave even more like a Windows editor.
I started out using evim and Cream, but found I gradually transitioned to using 100% vim.
Also if you use gvim then most of the functionality is also available through the menus and you can see the keystrokes for the same functionality.
Also read the docs - there are extensive help files available on every aspect. I still browse them from time to time and find something new.
Using VIM, I find the following quick reference card very helpful, especially for the stuff I don't do everyday:
VIM QuickReference
For emacs, you should read the GNU Emacs Manual. Don't try to do everything all at once.
Start with the basic stuff, and then move on to the more powerful features once you're comfortable with the easier stuff.
Some time ago I decided to learn vim beside Eclipse as well because of its powerful textual editing, search and navigation features. But - at the same time - I liked the project handling, code completion, refactoring and debugging features of Eclipse and I did not want to lose them.
Nowadays I use an Eclipse plugin called vrapper which provides me nearly all basic features of vim inside Eclipse without losing any Eclipse functionality. Of course it is not a full-featured vim but it gave me the productivity gain I 'expected' (motions, the dot operator, registers and marks). Also, this plugin can be considered the 'trial' version of vim where you can learn all basic and some advanced stuff within your 'best-known' environment.
There is another interesting approach called eclim. Eclim integrates Eclipse with vim from the vim side so you can use many features from Eclipse within vim.
For learning the basics of vim, this graphical cheatsheet helped me a lot.
I would go for Emacs.
Explicit command name will makes your task easier.
I switched to emacs after I had years of experience with vi and never looked back.
Go with tutorial first.
Hang out at #emacs in irc and people are happy to help you in real time, for whatever more you need.
My advice for learning emacs is to understand that everything is done by a command (written in elisp) that is connected (bound) to the key strokes that you make. The power of emacs comes from being able to write new commands and use commands that are not bound to keys (there are too many commands to bind each one to a command.) as well, of course, read and modify commands that are already in emacs.
Next learn how to use the Help key and how to make a key binding list, then how to search for relevant commands (apropos) and see if they are bound already.
Be ready to take learning diversions into the emacs manual (Help, Read manual, Emacs manual).
One argument in favor of Vim if you know Python is that you can write Vim scripts in Python. See :h python. Emacs requires you to learn elisp.
I find myself gravitating toward Vim for scripting languages like Ruby/Perl/Python/PHP, and for Emacs for languages that are more interactive (Lisp, essentially). If you develop your Python code using an interactive Python shell a lot, Emacs might be good, because you can embed a Python shell right into Emacs. If you write code and run it from commandline a lot, Vim can handle that easily enough via :make or :!.
I really recommend you learn both and pick whichever you like better. They are both worth knowing.
Wow, vi/vim vs emacs, what a temptation...
From a vi-user's perspective...
Always Therevi is on about every unix system ever released, in the default install, and available for Win
May save you from RSIvi uses home-row keys for just about everything, modifiers like control and meta are used only for rarely invoked functions and even shift-key use is moderate. This was probably all just a lucky accident, but don't laugh at RSI. It can happen to anyone, it's seriously painful, it's potentially career-ending, and it's hard to treat.
Starts up instantly.In the past, this was a huge advantage over emacs. Emacs users had to start up just once, and navigate everywhere within emacs. Today it starts faster, but in vi, it's perfectly reasonable to quit out of it entirely on every compile or test cycle.
Has an awesome line-mode The line mode in vi is backwards compatible to the original Unix ed(1) program, an editor that had only a line mode. That is, vi's regular-expression-substitution-engine-/-line-editor was once an editor all by itself.
Easily scriptableGot something you want to do to every .whatever file in your project? It's easy to write a declarative script that will edit a sequence of files. No need for imperative or procedural programming.
Easily extensibleVim, at least, can be extended in Python.
First of all, be humble.
As long as you remain aware that they are very powerful tools you'll be ok. If you are finding a task very difficult, and you are thinking 'it's just me that sucks not the editor', you're in the right mind to learn and improve.
Bram's 7 habits are a good tenets to go by
http://www.moolenaar.net/habits.html
Also I highly recommend having a go at writing a plugin. It doesn't matter what it does. It gives you the impetus to dive deep into the manuals.
Maybe, a good way is to learn vim/emacs while using eclipse. Try vimplugin or emacsplus plugins for eclipse.
This should really just be a comment, but against which answer ...
With Vim I'd suggest using the GUI version for a start, just dive in, the built-in help is excellent (:h and the screen splits adding a panel with comprehensive "hyperlinked" help pages). With vim the only potentially dangerous operation is a write, everything else you do is recoverable per command or edit (undo & redo).
The power acquired easily incentivises the learning.
Here's the way you learn: Start typing. When you hit a point where you want to do something other than typing, look up how you do that. Repeat. It helps to start with a few basics, say 7 fundamental commands. Other than that, when you run into wanting to do some operation, look it up and use it.
This great Tutorial was a big help for me for my first steps in Vim. It is a gently introduction and explain at the same time the philosophy of vim in a pleasant way:
aByteOfVim
The way I learned emacs was mostly by doing both of the following:
All the GUI menus show you the key-bindings you can use to execute the same command as that menu item. Pay attention to the bindings for the menu items you select a lot, and try them out manually next time you get a chance.
ctrl-h ctrl-h (think "Help! Help!") brings up a buffer that shows the various types of help available. If you then hit the "b" key (the buffer calls it "describe-bindings"), you will get a list of all the key bindings that are available in the buffer you are working on. Just peruse that every now and then with an eye for commands that look useful. Try them out when you get a chance.
As for vi, I learned it in the days before vim, so I pretty much had to use man vi to figure it out. Most of us emacs users will tell you that all the vi you need to know is :q! ("quit, and I really mean it"). :-)
But in truth if you are a Unix user you need to learn at least enough vi to do simple edits to config files and save them. You never know exactly what (if anything) you will get when you try to start emacs on a strange system Unix system, but vi is always there.
Nearly everything you see or interact with in Emacs can tell you about itself -- you just need to know how to ask it.
To learn Emacs, learn about the current Emacs context: what the values of things are, what the relations between them are, how they are denoted, how you can change them or otherwise interact with them.
The most important thing to learn is that Emacs is Emacs Lisp -- it is a Lisp ecosystem. Learning Emacs means also learning Emacs Lisp -- the more you know, the better. Lisp is the most flexible and most powerful way in which Emacs realizes itself as "the self-documenting, extensible editor".
Icicles can help you learn Emacs and Emacs Lisp. It helps you ask Emacs about itself. This page gives an overview of the ways it does that: Emacs Newbie with Icicles.
Don't get caught up in the vi(m) versus emacs religious war. They are both great editors. I originally started with VI (real VI not VIM) and later started using Emacs. These days, I tend to use both, but emacs more because emacs has some features I need which are not in vim.
The real challenge and what you should be aiming for is how to be as efficient, quick and accurate as possible with your editor of choice. Both VI and Emacs have a lot to offer in this respect. However, much of it boils down to two main habits you need to develop
Don't use the mouse. Both editors were created when mice were not the plague they are now. When it comes to editing, cutting, pasting, highlighting etc, both editors offer keyboard equivalents. Use them and keep your fingers on the keyboard. You will be surprised how much faster you will become
Avoid the arrow keys. This is for a similar reason. The arrow keys tend to make you move your hands off the main keyboard. In the end, this also slows you down and makes you less efficient. Both editors provide far more convenient functions which are faster.
These are the two main things to focus on when learning either of these editors. There is lots more, but to start with, just start with focusing on using the main keyboard.
After you have got that down pat, then begin to think about how you can tweak your environment to suit your needs. By this time, you will be familiar with the power of the editor you have chosen and will probably have some ideas. Both of these editors are very configurable. I find emacs is the most configurable, but you can easily get lost iin writing elisp to configure things and before you know it, your an elisp programmer who does a bit of PHP and Python. To some extent, the same can happen with VIM, but to a lesser degree. However, note that the defaults have usually been set by people with lots of experience and who probably know something you don't. Avoid making the mistake of trying to modify either editor to be what your use to. Learn how it works with minimal config first and then change once you have an idea of why it was done some way - know the rules before breaking them.
If your serious about programming, your editor will be your most important tool. Other important tools are your screen, your chair and your keyboard. The rest is incidental.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
As a programmer I spend a lot of hours at the keyboard and I've been doing it for the last 12 years, more or less. If there's something I've never gotten used to during all this time, it's these annoying and almost unconscious constant micro-interruptions I experience while coding, due to some of the most common code editing tasks. Things like a simple copy & paste from a different line (or even the same line), or moving 1 or 2 lines up or down from the current position require too much typing or involve the use of the arrow keys ...and it gets worse when I want to move further - I end up using the mouse. Now imagine this same scenario but on a laptop.
I've always considered learning VIM but the amount of time needed to master it has always made me want to step back.
I'd like to hear from people who have learnt it and if it ends up being one of those things you cannot live without.
At work, I use VS2008, C# and R#, which together make editing code a lot faster and easier than ever, but even so I think I could enjoy not having to use the mouse at all.
And not even the arrow keys.
I've been using vi and vim also for some 20 years, and I'm still learning new things.
David Rayner's Best of Vim Tips site is an excellent list, though it's probably more useful once you have some familiarity with vim.
I also want to mention the ViEmu site which has some great info on vi/vim tips and especially the article Why, oh WHY, do those nutheads use vi? (archived version)
Could I live without it? Easily.
Is it useful? Yes.
Reasons for Learning
vi is guaranteed to exist on all Unix systems and exists on most Linux ones as well. That kind of broad coverage makes learning it worth it.
It's much quicker to use vi for a sudo edit:
$ sudo vi
Also, GMail uses vi-ish commands for selecting & moving emails around!
You don't have to be a master.
Just learn
The basics:
How to switch from command mode to insert mode i
How to switch from insert mode to command mode Esc
How to navigate up a line in command mode k
How to navigate down a line in command mode j
How to navigate left a character in command mode h
How to navigate right a character l
How to save a file :wEnter (write)
How to exit without saving (in command mode) :q!Enter
How to Undo u
How to Redo Ctrl+r
You can combine writing and quitting (in command mode): :wqEnter
From there the rest will just make you faster.
Running through vimtutor only took me 30 minutes, which was enough to get familiar with vim. It was worth every second of it.
If you're a programmer who edits a lot of text, then it's important to learn an A Serious Text Editor. Which Serious Text Editor you learn is not terribly important and is largely dependent on the types of environments you expect to be editing in.
The reason is that these editors are highly optimized to perform the kinds of tasks that you will be doing a lot. For example, consider adding the same bit of text to the end of every line. This is trivial in A Serious Text Editor, but ridiculously cumbersome otherwise.
Usually vim's killer features are considered: A) that it's available on pretty much every Unix you'll ever encounter and B) your fingers very rarely have to leave the home row, which means you'll be able to edit text very, very quickly. It's also usually very fast and lightweight even when editing huge files.
There are plenty of alternatives, however. Emacs is the most common example, of course, and it's much more than just an advanced text editor if you really dig into it. I'm personally a very happy TextMate user now after years of using vim/gvim.
The trick to switching to any of these is to force yourself to use them the way they were intended. For example, in vim, if you're manually performing every step in a multi-step process or if you're using the arrow keys or the mouse then there's probably a better way to do it. Stop what you're doing and look it up.
If you do nothing else, learn the basic navigation controls for both vim and Emacs since they pop up all over the place. For example, you can use Emacs-style controls in any text input field in Mac OS, in most Unix shells, in Eclipse, etc. You can use vim-style controls in the less(1) command, on Slashdot, on gmail, etc.
Have fun!
It's definitely worth the effort.
There's one obvious reason that anyone who uses Vi(m) will tell you, and two others that people never seem to mention.
Here's the obvious one:
vi is at once ubiquitous and incredibly powerful, and by learning it once, you gain the ability to exercise that power on pretty much any computer that has a keyboard.
And these are the lesser known reasons to learn Vim:
It's not half as much effort as you think it's going to be. Run through the Vim tutor once (vimtutor at a shell, or in Windows run it from the Vim folder in the Start Menu), and you'll already be well on your way to competence, and it's all downhill from there. I was up to the level where I could use Vim at work without taking any noticeable productivity hit within less than a week's worth of lunchtimes.
It's fun! Editing text is like a game to me now. I actively enjoy it--which is pretty ridiculous, when you think about it.
There's also two good reasons not to learn Vim:
It's addictive, and you'll find yourself wishing you could use Vim commands in all your computing, and cursing whenever you can't. Fortunately, at least for some situations, there's ways to get around this.
Again, it's addictive, and although you won't lose any productivity from actually using Vim, you will waste hours searching for good tips to make your Vim experience even better, and reading the Vim tag on Stack Overflow.
It's definitely worth learning either vim or emacs. It's also worth learning to touch-type. In both cases the reasons are the same: your thinking is no longer interrupted by the mechanical process of getting your code onto the screen.
As to how to start, just dive in and start using vim for everything.
P.S. The emacs-vs-vi debate is endless. I've been using emacs for 26 years. If I started again today I'd learn vim because (a) it's gotten better and (b) there are many fewer modifier keys (Ctl-Alt-V, anyone) and vim users seem to get much less typing injury.
You can get good functionality out of vim by learning the meanings of only 16 keys: ijkdbw9:q!%s/nNEsc. You can do the bare bones with just i:wqEsc.
The first two keys you need to know are: Esc takes you to command mode (the mode you start in), and i takes you to insert mode (normal typing).
To save you need to
get out of typing mode (Esc)
type a colon :
type lowercase w then Enter
To save-and-quit you need to
get out of typing mode (Esc)
type a colon :
type lowercase wq then Enter
To not-save-and-force-quit you need to
get out of typing mode (Esc)
type a colon :
type lowercase q! then Enter
To learn more you can run vimtutor at the command line. It's a medium-length, well-structured lesson.
Beyond i and Esc: you can replicate or surpass some MS Word functionality with only jkwbd3:%s/nN.
b takes you back a word (Ctrl+←)
w takes you forward a word (Ctrl+→)
9w takes you forward nine words
db deletes the preceding word (Ctrl+Backspace)
d3b deletes three preceding words
9j moves down 9 lines
/ ornithopter Enter takes you to the next instance of the word "ornithopter", then n and N to the next and previous occurrence of "ornithopter" respectively.
:%s/confounded/dangfangled/ Enter substitutes every "confounded" with "dangfangled" (like find and replace all in MS Word)
Any of those should be run in "command" mode (Esc), not insert mode (i).
I recently switched to VIM, and I think it's worth it. If you need to "just get something done", you can always stay in insert mode, where vim is (mostly) like a normal text editor.
I've noticed that things that didn't use to bother me, like reaching for the arrow keys, now feel wrong and too much effort. It's definitely decreased my hand motion and usage of the mouse, which is good for both ergonomics and productivity
It depends what you want to do with VIM. It doesn't make sense to learn it only because many people cannot live without it.
When I was working a lot on UNIX environments, I couldn't live without it. Even when VIM was not installed on a UNIX machine, I could at least use vi. You could always count on it -- even if the machine is not yours (that from the customer).
Now I program in C# and mostly work on windows environment. I have installed VIM on my PC ... and I don't need it.
Evaluate if you really need VIM and if it supports you in your "flow of work". Try it out. Play with it. If you think you need it, stick to it ... the learning curve is very steep.
I learnt vi because I had to.
My crazy teacher forced us to learn to program in C using a terminal to an AIX system.
It was a real pain, but worth it.
Today, I only use vi for quick edits or small programs.
When I have to go for a project, I rather use and IDE. In my case IntelliJ idea is very good at the task, because I can code for hours without grabbing the mouse.
I don't know how much shortcuts does VS2008 has, but if they are as discoverable as Eclipse, I think you are in trouble go for vi.
If you DON'T edit code outside the IDE and your IDE has good shortcuts, you better learn those, and then, go and learn vi anyway.
:)
I've used vi/vim for 25+ years. If you already know some command-line editor, then maybe you don't need to learn vi/vim. But if you don't know any other command-line editors very well, it's worth learning it. It's pretty easy to be productive in vi/vim with little effort.
I use VIM pretty much exclusively now.
I used to use Vim for editing and VS Editor for debugging. This probably seems a bit crazy, but I found the Vi paradigm (macros, home key based editing etc) such a boost to my productivity, that editing in VS was paintful.
Thanks to Viemu, I don't even have to do the switching any more. It is not the perfect solution yet (code completion is sometimes not as elegant as in native vim and the macro recording isn't perfect), but it is much better than switching back and forth constantly.
The learning curve for Vim is probably exaggerated. I think once you get into it, it is pretty intuitive.
My job forced me to pick up vim and it has quickly become second nature. Now my complaints are about IDE's that do not have vim emulation or plugins. I do notice that the esc key has become my enemy outside of vim.
I did find several emulators for vi within Visual Studio:
http://code.google.com/p/vim-visual-studio/
Firstly good vi(m) knowledge will save you the time you have to hustle to do emergency editing of config files on a server under seige. It can hold up on a laggy ssh connection.
Admin stuff aside vim's input method will be your best defence against carpal tunnel if you use it effectively with an ergonomic keyboard.
The best way to see the point of vim is to start a casual project at home, unplug your mouse and tape over your arrow keys.
And read the help
Two advantages of vi/vim:
it is very light-weight
it is installed on almost every *NIX system
I am maintaining a very big linux project on the remote computer. There is no choise to use Eclipse or similar GTK based IDE. I've been working there for 3 years.
And I set my vim just for this project. And still tweaking.
Now I can do any thing from the Vim: source control, sql, debug, compile, browsing - really fast browsing over 1Gb source code.
Visual Studio or Eclipse couldn't handle all of this. And If I had a choice I would'n change Vim to other editor or IDE.
I learned Vim. It wasn't too much effort. Now I absolutely love ci" ci( cw V:s/from/to/g
I'd say vim is definitely worth learning. I picked it up last summer, and it is now my editor of choice for just about everything (java is a stretch, but doable when I don't need extensive analysis support). As everyone has already affirmed, it is a wonderfully efficient tool.
For what it's worth, I only learned a fairly small subset of vim's features (which took a day or two) from a graphical tutorial, and a few odds and ends from here (long read), and the search and replace functionality, and I was hooked. I've learned things since then, but at my leisure. I'd say the learning curve flattens out at this point, but then, I was using it pretty heavily and was surrounded by others who were, too.
I'm in the same situation as you, and as a beginner to Vim I originally found it a little daunting - the learning curve seems steep.
From what I've learned in just a few hours I'm already feeling like I won't be able to live without it.
Here are a few links that I've found for useful Vim screencasts to show you what it's capable of.
A good bit of advice that Bram Moolenaar (benevolent dictator of Vim) gave in that last link is that it would be inefficient to try to learn every single command and function, just figure out what it is that you're doing that isn't working very well, look for a way to make it more efficient and then make it a habit.
Yes, definately take the time to learn at least a bit of 'vi' and 'vim'. It travels very well.
You'll never be stuck when you are faced with a customer Unix/Linux/Mac system that you don't have install capabilities for. Even on Windows (if you do have install capabilities) 'Vim' is free and easy to install. (As opposed to investing your learning curve purely in something like UltraEdit, which although an excellent editor might not be available for you all the time...).
Learning vi can set you up for learning other tools like 'sed', and regex in general: stuff that is generally transferable.
Plus if you want to be a proper geek, you just simply need to know 'vi/m' or you'll look like a faker ;-)
I think it's definitely worth the time and effort to learn vim. To me, it makes typing and navigating around text so efficient, it's hard to imagine going back to emacs or ctrl/shift/alt/meta key combos.
Don't get intimidated by all the fancy features of vim. Once you've used it enough, you'll figure out which commands you use the most, and you'll figure out which things you can forget about.
The amazing ubiquity of Vim, and the even more amazing ubiquity of Vi-clones in general, on Unix systems alone is enough to make it worth learning.
Besides that, the whole Vi-style thinking is something that I really think has made me a bit more productive. For a person not used to modes such as the command mode and insert mode, it seems a bit excessive to have to enter a mode just to insert text. But, when one has been using Vim for a few months, and has learned quite a few tips and tricks, Vim seems to be an asset that seems to be worth it.
Of course, the Emacs crowd says the same thing regarding Emacs-style thinking, but I gave up on learning Emacs because Vim was simpler and did the job for me.
I learned to like vi after watching someone who was very skilled with it navigate around to make edits at an insanely fast clip. You really can code quickly with it. Another reason I like it is that sometimes I find that mousing around in an IDE really hurts my hands after a while and vi provides a nice change. As others have mentioned it's also almost always available on unix systems and works well even over lousy connections.
One thing that I haven't seen mentioned is that knowing vi has the added benefit of "geek cred" in some circles. I can think of at least a few people who chuckle when they see a new programmer fire up nedit to make some changes to a file.
Don't be scared off by the number of commands, I've not met anyone who used more than a couple dozen at most. I find it indispensable, because when I'm thinking about code I'm thinking about text, moving to thinking about mice just messes me up. The big tricks, I think, are to learn it a little at a time, and don't be hesitant to play around - the undo features is great for exploring its behaviors.
Also, if you get deeply into it, vim is scriptable. The possibilities are literally endless.
(Yes, all of this applies to emacs too...)
I was happy at my textpad and ecplise world until i had to start working with servers running under linux. Remote scripting and set up of config files was needed!
It was hard at the begining but now i can easily set up and tune up my servers.
You might want to learn vim because you might not be happy with the editors you're already using.
You might want to learn vim because many people say it is cool. Just look how many answers you've got to this question.
I will provide an additional reason for learning vim. It has a reputation for the quality and the completeness of its docs. So you will find most answers to your questions in its help system as soon as you will manage to stick the proper keywords in your help queries.
To learn vi(m) fast one must first understand the whole design.
Vim has a great set of cursor-movement commands, check a few (X is a character, # a digit):
j k enter arrows
0 $
w W b B
ctrolD crtolU
ctrolE ctrolY
H M L
fX FX tX TX , ;
%
gg G
n N
mX 'X ''
and many more it would be boring to enumerate. Many of these support a count before the command, like 4j to move 4 lines up.
Now, back to the design, you type a command like d for delete followed by a cursor movement and the command applies to the piece of text from the cursor position till the movement end. For example H moves to the top of the screen, dH deletes to the top of the screen and cH changes (replaces) to the top of the screen.
This design is quite powerful. It also reduces, or organizes, what you need to learn.
Definitively the first step is to learn a few cursor movement commands. Say,8 or 10 at first. Then you are almost done.
Learning something new is always worth the effort, IMHO. I suggest you print out a cheat sheet and force yourself to use it day-in and day-out.
Vim is definitely worth learning to partly summarize what has been stated previously here are the main reasons:
Vi/Vim can be found on most unix systems.
Vim allows you to easily code without taking your hands off the keyboard.
If you plan you configure anything in a unix based system likelihood is you going to be editing a fair few config files, therefore you'll want to learn a terminal based editor, of which vim is one of the best (sorry emacs).
Vim compiles/has precompiled binaries for almost every OS out there. No need to post "I need a textmate alternative for [insert OS]", you'll have Vim instead!
There are a lot of good plugins out there to add alot of functionality, such as in-editor cvs diffs, although some of these require a fair amount of tinkering.
Also on a side note if you find you like the Vim key bindings, there are also IDEs which include vim bindings in their editors for simple commands, for example Komodo Edit.
For help on learning Vim, try typing 'vimtutor' into your terminal and follow the instructions. There is also a book which is particularly good Hacking Vim
No. Learning vim is worth more than the effort.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Right up front: I do not want to start a religious war.
I've used vi for as long as I can remember, and the few times I've tried to pick up Emacs I've been so lost that I've quickly given up. Lots of people find Emacs very powerful, however. Its programmability is somewhat legendary. I'm primarily doing Solaris+Java development, and I'd like to ask a simple question: will my productivity increase if I invest time in getting my head around Emacs? Is the functionality that it offers over Vim going to be paid back in productivity increases in a reasonable timeframe?
Repeat: I don't want a "my editor is better than yours" answer. I just want a yes or no answer as to whether it's worth investing the time or not. Will my productivity really increase?
[Disclaimer: personally, I prefer Vim. Disclaimer disclaimer: read on.]
Vim excels in the small: by making motion and action separate concepts and providing facilities for complex repeats, you can perform incredibly powerful editing operations in just a short sequence of keystrokes. You can easily do things in Vim in the normal course of editing that would require you to drop down to scripting in Emacs. Also, most of the power you use comes out of the box, so even if you have extensive .vimrc customisations, chances are you will be able to work productively with any Vim installation.
Emacs excels in the large: by mapping all of its UI concepts directly to basic constructs and concepts in Elisp, it becomes very easy to globally introduce features for specific kinds of files or circumstances, making Emacs something like a text-based and much more structuredly programmable form of Excel. This presumes that you are going to spend a lot of time customising your environment for personal needs and preferences. Of course, Emacs does do its best to make it easy to stay inside that one environment for everything and anything you may want to do.
Ultimately, neither is superior. They offer different styles, and depending on your proclivities, one or the other will suit your personal needs and way of thinking better. It is always helpful to know both (plus more editors), of course. But you aren’t going to be appreciably more productive this way or that.
I prefer emacs to vi, but I'm comfortable in both.
There are some things that you can do in emacs that make it more powerful than vi, but not all of them are even programming-related. (Can you send email or read news from within vi? No, but who cares?) If you're comfortable with lisp (I'm not), you might be able to write add-ons and modes and stuff to make your life easier, but that's just likely to be syntax colouring and brace matching and eye candy like that.
I will stop rambling now. Will your productivity increase using emacs? No.
Update: See my comment below. Since I posted this, I have come across ways that using emacs has made me more productive than using vi.
vi is a kitchen knife.
vim is a really nice, sharp, balanced chef's knife.
Emacs is a light saber.
Most of the time, my job requires me to chop vegetables. Occasionally, I have to take on an entire army of robots.
I've been using Emacs for 20 years. I'm typing in Emacs right now with a widget called "It's All Text" that lets me suck text in and out of text boxes in Firefox. I can go really fast in Emacs. I am significantly less productive without it.
This is highly debateable, but I also think that learning Emacs can teach you a surprising amount about programming.
Depending on how you code, you may see a productivity increase. For background, I'm also a long-time vim user, but I learned emacs about 2 years ago, and now use them interchangeably.
What drove me to the point of actually learning emacs was its useful ability to have a large number of files open at once, and to easily switch between them. I was in the middle of introducing a feature that added and touched a large number of classes. (This was C++, so there were typically two files per class.) Since I was still firming up the interface, I would typically be in the middle of updating one file when I would realize that I needed to change another.
With gvim, it was easiest to open a new window for each file, which was starting to get unwieldy. With Emacs, though, it was simple to open a new file in the same window (Ctrl-x, Ctrl-f). Once Emacs has a file open, it's very easy to switch back and forth between the open buffers (Ctrl-x, Ctrl-b).
Taking that one step further, a single emacs session may open many windows, so in addition to splitting the window vertically, I could decide, without interrupting work on a file, to open another next to it, letting me effectively work side-by-side while still keeping each window at the default 80-character width.
There are still some things that I find easier in vim (e.g. block-select mode, simple macro recording, diff mode), and things that are easier in Emacs (line alignment, file/buffer management, window/screen management). Therefore, I find myself alternating between the two (and sometimes using both simultaneously), depending the editing task I anticipate.
If you're still unsure, I'd suggest trying it out. Run through the Emacs tutorial and then use it to write code for a morning or a day, leaning heavily on the help. If you still don't like what you see, stay with vim. Regardless of what the editor brings to the table, your familiarity and knowledge of the tool will by far be the most important factor in your productivity.
I don't want a holy war, but please answer a highly subjective question with a yes/no answer.
Yes, you may see a productivity increase because of the powerful functionality.
No, you will not see a productivity increase because the patterns and metaphors used in emacs may not align with you brain.
The short answer to your question is, "YES". More detail below.
I used vi almost exclusively from about 1980 to 1991. The only time I didn't use vi was when I was dealing with a minimal install of Unix that was too small to include vi, so I had to drop back to ed which is the minimal subset of editing functionality that the original vi was built on top of.
From about 1985 on, other programmers where I worked were constantly singing the praises of emacs. But every time I'd try to learn it I wouldn't get very far. I'd spend an hour going through the emacs turorial (C-h t) and by the end of it all I'd know would be how to insert and modify text and move around the screen. I could do so much more with vi than what I'd learned in that hour with emacs that I couldn't make the switch. Three months later I'd find time to spend another hour and I'd end up going through the same material. Emacs has a Learning Curve with a capital "L". It wasn't until I was doing a contract where everybody else used emacs that I eventually decided I needed to devote more than an hour at a time to learning it. After spending a little over a day doing nothing but working through the tutorial and the included documentation, I finally got to the point where I could do things with emacs that I couldn't with vi. From then on, I've never wanted to go back. I can still type vi commands in my sleep, but I can do so much more with emacs.
Understand that I'm comparing emacs and vi, not vim. I've never learned the extensions that vim has added to vi, and it's likely that many of them are features copied from emacs. If so, and if you're already proficient with vim, emacs may not hold as many advantages for you.
Among the things I depend on all the time in emacs are:
When you use emacs, everything's treated as text. This means that you can manipulate any data in any buffer with pretty much the same commands. And in cases where a buffer's in a mode where some of the standard commands are unavailable, you can copy text to another buffer running in fundamental mode and use the standard commands there.
Emacs provides a multi-"window" environment displayable in on a character-cell terminal. In the days before bitmapped graphics and real windows, emacs was written to simulate window-like behavior using nothing but ascii characters and cursor positioning. You're probably thinking, "That's ancient history. Why should anyone care about that today?" I still use that capability every day. I use a webhosting company that allows me SSH access. So I can log into a Linux host across the Internet and run shell commands. While that's pretty powerful, it's far more powerful to be able to divide my terminal emulator up into "windows" using emacs, run shells in several of those "windows", edit files in other windows, and view and edit directories in still other "windows".
Actually, when I said "window" in the previous paragraph, I really meant "buffer". Emacs' character cell emulation of windows is a way of dividing up the screen real-estate. An emacs buffer is associated with content (a file, a bash shell, a directory, arbitrary text not associated with a file, etc.) which may or may not currently be displayed. To view what's in a buffer, you pick a window and tell it what buffer you want to see. So you can be working on way more things than you have space on the screen to display. It's roughly analogous to what you do in a modern bitmapped-graphics GUI when you iconify/de-iconify a window.
I've already alluded to the fact that you can run a shell inside an emacs buffer. You can have as many buffers running shells as you like. You can copy and paste text back and forth between a shell buffer and a text file, or compare a portion of text between a shell buffer and a text file using the exact same keystroke sequences you would use to copy text or compare text between two different text files. Actually, this is true for most types of buffers, not just shell buffers and buffers associated with files.
When you use emacs' command to open a file, but what you've selected is actually a directory, the buffer runs in dired (directory editor) mode. In this mode, a single keystroke will open whatever the cursor's currently pointing at, be it a file or subdirectory. A buffer in dired mode is a file manager - a character-cell terminal oriented analog to Finder on the Mac or Windows Explorer.
One of the emacs functions I use almost constantly is "compare-windows". I greatly prefer this to command-line "diff" or GUI comparison tools like what's built in to Eclipse. Diff or Eclipse compare entire files, and show you which lines differ. But what happens when you have two different lines that look very similar? Consider the following:
What's the difference between this line and the other?
What’s the difference between this line and the other?
How long would it take you spot the difference? (Hint: ASCII and Unicode apostrophe look pretty much alike.)
Unlike diff and Eclipse, which just show the lines that differ, emacs' "compare-windows" function is interactive. You position the cursor in each of two side-by-side windows at a point where the window contents are the same. Run "compare-windows", and the cursor in each window will move to the first character that differs. Reposition the cursor in one of the windows to the point where it's the same as the other window, and rerun "compare-windows" to find the next difference. This makes it easy to compare subportions of files.
Another thing I regularly use "compare-windows" for is comparing checksums. Many software projects distribute a tarball of the application on a page that also includes an MD5 hash of the tarball. So, how do you compare the MD5 hash on the distribution page with the MD5 hash computed from the downloaded file. Emacs makes this trivial.
First copy the MD5 hash from the webpage into a new emacs buffer. Then, after downloading the .tar.gz file, run:
md5sum downloadedfile.tar.gz
in a shell buffer. With those two buffers displayed in side-by-side emacs windows, position the cursor in each window at the beginning of the checksum and run "compare-windows". If they're the same, the cursor in each window will be positioned at the end of each checksum.
In the previous point, I gave the example of running "compare-windows" on the lines:
What's the difference between this line and the other?
What’s the difference between this line and the other?
"compare-windows" will leave the cursor positioned on the apostrophe in each line. So, now you know which characters differ. But what characters are they? Type the two keystroke command CTRL-x =, and emacs will display the character, its ascii value in octal, decimal, and hex, the character offset from the beginning of the file, and the character offset from the beginning of the line. Since ASCII is a 7-bit encoding, all ASCII characters have their high-order bit turned off. Once you see that the value of the first apostrophe is 0x27 and the second one is 0x92, it's obvious that the first one is in the ASCII character set and the second one is not.
Emacs was one of the first IDEs, perhaps the very first one. It has modes for specific languages. I find them handy for imposing consistent indentation on my code to make it more readable. There's also built-in functionality for compiling and debugging code. I don't use the compiling functionality that much because when I was writing for a compiled language like C, I was used to doing that at a shell prompt. The debugging functionality was very nice for C and C++. It integrated gdb with the editor in such a way that you got pretty much the same functionality as the debugging capabilities now in Eclipse, but didn't waste screen real-estate the way modern GUI-based IDEs do. Theoretically the debugger integration should be easy to make it apply to virtually any other language, but I haven't checked to see what other languages it works with nowadays.
Emacs allows you to create macros by telling it when to start remembering what you're typing and when to stop. This is extremely powerful for tasks you frequently do.
Emacs is infinitely extensible if you know Lisp. But even though I've never learned Emacs Lisp, I still find Emacs one of the most powerful tools I've ever used.
Emacs key-bindings. I'll be the first one to admit that Emacs key-bindings suck. But it's so much more powerful than anything else I've used, that I'm willing to put up with the key-bindings.
In a humorous vein, years ago Emacs' author Richard Stallman (also originator of the GPL, founder of the GNU project and founder of FSF) lampooned those who treat vi vs. emacs as a holy war. He invented the character "Saint IGNUcius" of the Church of Emacs. In that guise, Stallman commented, "Sometimes people ask me whether it is a sin in the Church of Emacs to use the other text editor vi. Well, it's true that vi vi vi is the editor of the beast, but using a free version of vi is not a sin, it's a penance." (See http://stallman.org/saint.html. There's also a cute photo of him, but since I'm new to StackOverflow, it won't let me post more than one URL. So go to the same domain, but fetch the file saintignucius.jpg)
I used Vim for 10 years leading up to delving into Emacs 2 years ago. I have a reasonably fresh recollection of just how my productivity curve modified over time.
My points are all conditional, YMMV depending on your strengths and experience.
If you have used Unix and the command line long enough that you are familiar with C-a, C-e, C-n, C-p, C-k, C-y, etc as they function on the shell, it will not take long to transition to using those same bindings (the defaults) in Emacs. I recently discovered that XCode uses these bindings as well.
If you are comfortable with an always running editor, tending buffers (like you would browser tabs) and thus living in the application (like you would with Web2.0 apps in the browser), Emacs will likely show immediate productivity enhancements.
If you generally work in projects of many related files, this persistence pays some added benefits in maintaining context to that buffer. Each buffer is contexted at its open file allowing for convenient use of various productivity boosting tools for your that project (like grep-find, eshell, run-python and slime). This coupled with text completion, yasnippets, etc start to look a tiny fraction like an IDE although ad-hoc and heavily individualized by your configuration. This is apart from more civilized Emacs IDE-like services like ECB.
My productivity took a hit initially as I typed "jjjkkk" constantly Esc-Esc-Esc-Esc for the first week or so. The following week I cautiously started using the right navigation keys. Then I discovered the configuration file... Honestly, if I had had Emacs Starter Kit from the start, I would have said my productivity slowly worked back to parity over the 3rd-4th week but I did go down the config file rabbit hole. A co-worker of mine, though, has just transitioned from vim to emacs and he just grabbed the Starter Kit and he is on his way. First week in and he seems comfortable and enjoying all the surprise benefits (that sensation will probably last a decade).
Finally, if you make mistakes you will immediately gain productivity (and confidence) from the circular kill/yank-ring and undo-ring. I am also personally a fan of region specific undos.
My short answer is Yes it is worth taking 3-4 weeks of a diminishing productivity-hit to learn Emacs. Even if you decide you prefer a streamlined unix utility combo over Emacs for development you will derive from it an education widely applicable beyond the editor.
Emacs documentation is a forest. I came from Emacs to Vim when I realized how organized Vim's documentation is, and how chordable many of the features are. I don't know what lies down the path of an Emacs expert, but I will warn you that learning to do anything useful in it takes a long time, and won't make you any better at nethack. Stick with Vim.
Textmate is a better Emacs for Macs, though that won't help you with Solaris. Eclipse is kind of cool, and has a lot of plugins.
Emacs will provide a productivity gain if you're willing to learn and customize it to fit your needs. Most people are not. To increase your productivity you must use the tool for more than simple editing - most people never progress past simple editing.
Here's a quick test: have you customized your window manager to make your environment more efficient (tailored to fit your needs)? If 'no' then likely you will not get the ROI by learning emacs.
That being said, if you're developing Java, Eclipse is the standard answer, so your question is pretty moot.
I was very happy with my Vim, but once I heard of org-mode, I started learning Emacs.
org-mode could be one strong reason to learn Emacs.
I love emacs and use it every day.
That said, I don't think the cost of learning it will be recouped by productivity gains down the road.
If you're programming Java, you need a good IDE. Emacs goes a fair way towards being one, but let's face it, IDEA et al beat it hands down. (emacs probably inspired a lot of those IDEs, but that's another story).
Twice I've tried to learn Emacs. It just doesn't fit how my brain works, and so I don't use it.
Emacs (or vim) is not significantly better than vim (or Emacs). Both have many options to add to them that allow them to do amazing things. I have no doubt that anything you can get done in Emacs you can also get done in Vim, just not standard.
Try Emacs. See if it fits better. It's a no-lose situation.
I want to look into emacs further, but I just can't use it for long stretches of time; it hurts my hands. Am I doing something horribly wrong?
vim and emacs, they are THE most capable editors and have been for quite some time.
If you know one really well, I doubt that you will gain that much in the process...
However, it is always a good idea to look into what plugin that are available since
a couple of new plugins can do wonders for the productivity.
/Johan
No (and I've used both).
Along the same line of not looking for a religious war (but go ahead and downvote me if you feel you must), why do you feel that the only option to vi is emacs? Is it the OS you develop on, or just the options you explored?
The Java development landscape enjoys some of the best IDEs these days (both free and paid for), if not the best when it comes to code editing and refactoring support.IntelliJ IDEA even has a vi plugin that can help you feel more at home, for instance (not sure if something similar is available for Eclipse). While changing tools does imply a learning curve, the time spent doing it might be worth it if the leap is big enough.
How fast do you type? If you hunt and peck, then emacs is not for you. If your fast tho, it can help not having to grab your mouse all the time.
Generally, emacs is more powerful than vi. You could do a lot more things in emacs.
You're productivity will increase if you decide to put the time in to program your text editor. Of the two editors, emacs presents a better framework or constant customization. If you don't program your text editor, just stay with what is comfortable.
One good reason to learn Emacs is because other programs use Emacs keybindings too. You can use Emacs keybindings at a bash prompt, for example, or anything else using GNU readline. It's good to learn the basic movement and word/line deletion and undo/redo chords in Emacs so that you can use them in other programs. Your productivity will increase in those other tools even if you never use Emacs again.
I know Vim and Emacs, and Vim fits my brain and my habits better. But other people claim the same about Emacs. You never know for yourself unless you try. It doesn't take that long to learn Emacs well enough to see whether you're going to like it.
Will my productivity really increase?
For the first few days/weeks, absolutely not.
After you stop having to read through the tutorial every time you want to edit something - sure..
Emacs is more "powerful" than vim, it's scripting engine is far more flexible, and there are far more scripts, modes and the likes built around emacs.
That said, the opposite is true.. If you spent the same amount of time improving your knowledge of vim, you'd could be just as productive..
Maybe not productive in the same way - I'd say vim is quicker for editing files, emacs is better at doing everything else (again, I would personally say things like flymake-mode, VCS bindings are such are quicker to use than the vim equivalent)
I agree with Alan Storm: "because the patterns and metaphors used in Emacs may not align with you brain"
This is a very important factor. Different brains adapt differently to different interfaces.
Some of the main - and easily available - features I really love Emacs for, and I count as productivity enhancers:
1. "yank-pop" facility - every cut/copy is saved into a stack so you can later choose which to paste (don't know if vi / Vim has this but most Java IDEs don't)
2. the Ctrl-key navigation mapping - this allows you to navigate your file without moving your hands off to use the arrow keys. (key-binding in other editors helps of course)
3. available on almost every platform (true of vi/Vim too of course) - whether GUI- or text-based (Java IDEs are available on most platforms too but only in GUI mode, and are significantly larger and need to be installed separately whereas Emacs is generally more widely available - BSD / *nix / Linux / Mac systems
4. I prefer my editor to stay out of the way until I need it - Emacs' spartan display forces me to think before I type.
5. The basic navigation keys in Emacs are kind of universally available - on my Mac OS, I can use these keys in terminal, mac mail, etc.
Ultimately, if Emacs' philosophy appeals to you, you will put in the extra effort to learn it. And it will reward you.
Since vi/Vim and Emacs are pretty close in terms of what they can or cannot do, productivity with these two editors comes from experience in using it.
In my opinion, being a programmer it won't take you long to get the general idea about Emacs once you start using it. Others can only say so much, you got to try it out for yourself to know it.
As for me, I use both. It's like taking more than one weapon to a war, use the right one in the right circumstances. ;)
I like Emacs, you can extend it by your needs- in my eyes, any system which you can extend by yourself is award-worthy.
Disclaimer: I'm ignorant. I've been an emacs user for about 4 years, and vim user for about 6 months, maybe more like 15 if you count all the times I've tried to learn it and hated it. (The writing vs moving mode distinction kills me. Every time. So if it doesn't kill you then my opinion might be completely worthless.) That said, I think my opinion is actually interestingly different from the 26 others that I've seen on here, so I'm going to voice it.
:Disclamer
My opinion:
Emacs is better for typing, especially large-scale "I'm writing a new feature and it will be a while before I even try to see if it runs".
Vim is better for editing, especially quick edits.
When I need to understand and hack in 8 files simultaneously, Emacs' properties as a tiling window manager with multi-buffer (buffers have a 1.2:1 correspondence to files, they're often the same thing, but aren't necessarily) regexp-search (and replace) are incredible.
If I don't like some small thing because of git diff in the shell (I don't use emacs' VC features very often, although when I do I love them) I open it with vim and get the hell out faster than I could hit Alt-TAB.
The fact that Emacs' editing commands are more readily available while typing make typing much faster than it is in Vim. Ctrl+a is much faster than ESC ^ i, and you don't have the cognitive load of "do I want a or i or o or O..." which, god, I hate thinking about. And same for all the other movement commands commands.
I type faster, much faster, in Emacs. That means things like Org Mode (which I use for everything: TODO lists, bug tracking, notes, long emails, documentation...) make more sense (to me) in Emacs than they would in Vim.
And, Elisp is incredible, even though it sucks. It totally makes up for Emacs' broken regular expressions: you can use the full power of emacs everywhere, including in a multi-file regexp-replacement. And in text snippets.
If you are concerned about the health of your hands choose Vim.
I suffered from a bout of RSI in the past, and I found one of the main culprits was "chording" i.e. holding down many keys at the same time. Emacs uses chording extensively whilst VIM uses single letter commands chained in quick succession. This puts much less strain on your hands as the muscles don't have to twist and contort to perform commands in the editor. Injury due to RSI can ruin your productivity so in your calculations be sure to account for this.
I really see no reason to switch. I've used vi for a long time and am quite comfortable with it; about every six months I would install emacs to give it a go, then quickly just switch back. Yes there were things I much preferred about vi, but the main reason I never stuck with it is because the time investment to fully learn another editor when I already know an extremely capable one isn't worth it.
I'm reminded of this rather dated study.
In my opinion, SLIME is about the only reason to switch to emacs if you're already proficient with vi.
No
I've been using emacs for years, I'm a convert from VIM, and I love it to bits.
But any productivity gains from having a better, programmable editor will be totally wiped out by the enormous amount of head-fucking that it takes to get the hang of emacs. It was designed as a console editor, and its idea of interface is not yours.
And even when you've got it completely, your extra productivity will mainly be expressed in the extra emacs lisp you can write.
Who cares? It's great fun, and lisp is the dogs! If you want to 'get things done', then forget about programming. You can always hire programmers to 'do' 'things'.
The only circumstance under which I'd recommend learning emacs for productivity reasons is if you're a lisp/scheme/clojure programmer. It makes such a good lisp environment that then the few seconds it will save you every time you want to do anything will quickly add up to a real gain. And elisp (which stands in relation to lisp as excel macros stand to ALGOL) will seem much less alien if you already use a real lisp.
If you do give it a try, use it on a virtual console where it feels more like a sane way to arrange an editor. Only when that makes sense try to use it under a window system, which will fight with it.
In an earlier answer, Aristotle Pagaltzis wrote: "Vim excels in the small ... You can easily do things in Vim in the normal course of editing that would require you to drop down to scripting in Emacs."
I switched to Emacs after over a decade of exclusively using vi, and initially I would have agreed with the claim, "You can easily do things in Vim in the normal course of editing that would require you to drop down to scripting in Emacs." But then I discovered that by using Emacs' macro capability and a large repeat count, I could easily make Emacs do pretty much everything that vi had made easy, and a great deal more.
Emacs' macro functionality involves three commands:
C-x ( start remembering keystrokes
C-x ) stop remembering keystrokes
C-x e replay the remembered keystrokes
For example, in vi if I wanted to find all <a> tags in an HTML file
and add a target attribute, I might do something like the following:
:g/^<a/s/>/ target="_blank">/
This example is not perfect, since it assumes that all <a> tags are on a line by themselves. But it's good enough for illustrating how one accomplishes the equivalent task in two different editors.
To achieve the same effect easily in emacs, here's what I do:
1. C-x (
2. M-C-s <a\>
3. C-b
4. C-s >
5. C-b
6. target="_blank"
7. C-x )
8. C-u 10000 C-x e
Here's a description of what each keystroke above does:
1. start remembering keystrokes
2. regex search for <a. Note that the "\>" after the "a" is not HTML. It's emacs regex notation for end-of-word.
3. back up one character - as a side-effect this gets you out of search mode
4. search for the next ">"
5. back up over the ">"
6. enter space as an attribute-delimiter followed by the target="_blank" attribute
7. stop remembering keystrokes
8. replay the remembered keystrokes 10,000 times or until the search fails
It looks complicated, but it's actually very easy to type. And you can use this approach to do lots of things that vi can't do, without ever dropping down to Lisp code.
I've been using Lisp on and off for a while but I'm starting to get more serious about doing some "real" work in Lisp. I'm a huge Vim fan and was wondering how I can be most productive using Vim as my editor for Lisp development. Plugins, work flow suggestions, etc. are all welcome.
Please don't say "use emacs" as I've already ramped up on Vim and I'm really enjoying it as an editor.
Limp aims to be a fully featured Common Lisp IDE for Vim. It defaults to SBCL, but can be changed to support most other implementations by replacing "sbcl" for your favourite lisp, in the file /usr/local/limp/latest/bin/lisp.sh
When discussing Lisp these days, it is commonly assumed to be Common Lisp, the language standardized by ANSI X3J13 (see the HyperSpec, and Practical Common Lisp for a good textbook) with implementations such as GNU Clisp, SBCL, CMUCL, AllegroCL, and many others.
Back to Limp. There are other solutions that are more light-weight, or try to do other things, but I believe in providing an environment that gives you things like bracket matching, highlighting, documentation lookup, i.e. making it a turn-key solution as much as possible.
In the Limp repository you'll find some of the previous work of the SlimVim project, namely the ECL (Embeddable Common Lisp) interface, merged with later releases (7.1); Simon has also made patches to 7.2 available yet to be merged. The ECL interface is documented in if_ecl.txt.
Short-term work is to do said merging with 7.2 and submit a patch to vim_dev to get it merged into the official Vim tree.
Which leads us to the long-term plans: having Lisp directly in Vim will make it convenient to start working on a SWANK front-end (the part of SLIME that runs in your Lisp, with slime.el being the part that runs in the editor - the frontend).
And somewhere in between, it is likely that all of Limp will be rewritten in Common Lisp using the ECL interface, making Limp easier to maintain (VimScript isn't my favourite) and being easier for users to customize.
The official Limp site goes down from time to time, but as pointed out, the download at Vim.org should always work, and the support groups limp-devel and limp-user are hosted with Google Groups. Don't hesitate to join if you feel you need a question answered, or perhaps even want to join in on development. Most of the discussion takes place on the limp-devel list. If you're into IRC, I'm in #limp on irc.freenode.net as 'tic'.
Good luck!
You might give slimv a break.
Here's a cool diagram by Xach that sums up the current situation.
Here we are 9 years later, and now we have Vim 8 and Neovim, both providing the ability to interact with plugins asynchronously.
vlime is an excellent, feature-rich plugin that takes advantage of the new async interface to provide a SLIME-like dev environment for Common Lisp.
Check out the Limp plug-in:
http://www.vim.org/scripts/script.php?script_id=2219
SLIME for EMACS is a wonderful tool for LISP programming. The best part is sending code written in your editor straight to a live LISP session. You can get similar behavior out of Vim using the tips here:
http://technotales.wordpress.com/2007/10/03/like-slime-for-vim/
I adjusted my own script so that I can send to either a SBCL or Clojure session. It makes you much more productive and takes advantage of the REPL.
":set lisp" starts the lisp indentation mode for Vim. But it won't work with some dialects like Clojure. For Clojure, use VimClojure.
Some people like LIMP also.
:set lisp
Vim has a mode to help you indent your code by Lisp standards.
Also, I modify the lispwords to change how vim indents my code.
:setl lw-=if (in ~/.vim/ftplugin/lisp.vim)
You can give Emacs with Vim emulation a try, is not perfect, but it may be somewhat familiar. I think Lisp shines if you use something like Slime or DrScheme doing iterative development, all other editors feel just wrong.
Vim add-ons: Rainbow Parentheses, Lisp syntax
SBCL add-ons: rlwrap, sb-aclrepl
Workflow: Ion3 (or some other tiled WM) with multiple terminal windows.
Edit Lisp in Vim
Switch to Lisp window (using the keyboard of course)
Use C-r to recall the line to reload the ASDF system in question so your changes become active.
Use X Window copy/paste for small snippets/changes.
Use DESCRIBE, TRACE and APROPOS heavily.
Repeat.
There seem to have been attempts at having a SLIME-like integration of Lisp in Vim, but none have really gone as far as needed to be really useful. I think ECL's integration has been done, though, but not committed upstream.
You should find all relevant links from Cliki's page about Vim.
I know you said not to tell you to use Emacs.
Use Emacs.
Serious, the SLIME setup for Emacs is pretty much the standard development platform for Lisp, and for very good reason.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
A good while ago, I read an article by the creator of viemu, clearing up a lot of the misconceptions about vi, as well as explaining why it's a good idea (and why it's been very popular for the last 30 years+). The same guy also has a great set of graphical cheat sheets that teach the basics a few bits at a time.
I'm convinced.
I've been convinced for the past 2 years in fact. But I still really haven't gotten around to force myself to learn vi as my primary editor, the learning curve is just too high. When I get down to work, acceptable but immediate productivity (using my current editor) has so far won over tremendous productivity farther down the line (using vi).
Does anybody have any good tips to help get past the learning curve? It can be straight out tips, some other tutorial or article, whatever.
Edit: Note that I'm aware of the vim/gVim, Cream and MacVim (etc.) variants of vi. I kept my question about vi to refer to the vi family as a whole. Thanks for all the great answers.
Update (April 2009)
I've been using Vim (more precisely, MacVim) in my day to day professional life since last December. I'm not going back :-)
Good luck to everyone in their Vim mastery.
First of all, you may want to pick up Vim; it has a vastly superior feature set along with everything vi has.
That said, it takes discipline to learn. If you have a job and can't afford the productivity hit (without getting fired), I'd suggest taking on a weekend project for the sole purpose of learning the editor. Keep its documentation open as you work, and be disciplined enough not to chicken out. As you learn more, become efficient and start relying on muscle memory, it won't be as hard to stick with it.
I've been using Vim for so long that I don't even think about what keys to press to search or navigate or save. And my hands never leave the keyboard. To use Vim is one of the best choices I've made in my programming career.
The first thing I'd do is lay a piece of paper or a book over your arrow keys and your ins/home/end/pgup/down keys. Those aren't needed in Vi.
Next I'd get used to hitting ctrl+[ whenever you're told to hit escape. It's much faster and you won't need to take your hands off the keyboard.
Then I'd watch my screencasts:
http://www.youtube.com/watch?v=FcpQ7koECgk
http://www.youtube.com/watch?v=c6WCm6z5msk
http://www.youtube.com/watch?v=BPDoI7gflxM
http://www.youtube.com/watch?v=J1_CfIb-3X4
Then, just practice practice practice.
edit
The reason for avoiding the arrow keys is that they slow you down. One of the largest benefits of Vim is the speed it allows you. The arrow keys also prevent you from really embracing the modal nature, which is very powerful when mastered.
Step 0: learn to touch type. Seriously - if your fingers don't know where the keys are then vim is going to be a pain. And even if you reject vim, touch typing will improve your programming (ask Steve Yegge ) by making the mind to monitor link friction free. There is a lot of software that can help you improve your typing.
Step 1: use vimtutor to get you started. It is in gvim (under
the help menu I think) or you can just type 'vimtutor' at the command
line. It will take 30-45 minutes of your time and then your fingers will
know the basics of vi/vim and you should be able to edit files without
wanting to hurl your keyboard out of the window.
Step 2: use vim everywhere. See this
question
for tips and links for using vim and vi key bindings at the command
line, from your web browser, for composing emails, in your IDE ... You
need to use vim to embed the key bindings in your muscle memory.
Step 3: learn more about vim. You will only have scratched the
surface with vimtutor. You can watch this
video or
read this article (both about
the "Seven habits of effective text editing". You can
read
about
tips
and
tricks
on
StackOverflow.
You can browse vimtips. Learn a
litle often would be my advice - there is so much out there that
sticking to bite-size chunks will be the best way to make the knowledge
stick.
Step 4: Profit :)
I've been a on-again, off-again user of vim throughout the years (doing the occasional sys admin job). I just recently started spending more time doing my programming work in it. I'd suggest starting with gvim too. It integrates well with most OS environments, and (even better), you can fall back to the mouse when you need to :).
To get going with vim, run through the vimtutor (bundled with gVim) once or twice (takes an hour or so). I can't overstate how helpful it was for me! Especially the first parts about the different ways to move through a document, and how edit actions are recorded with motion commands, etc, etc. After that, things will be MUCH clearer.
Then, start doing quick, minor edits with it (notepad-replacement stuff) 'till you are comfortable enough to do useful editing at a rapid clip. Then try doing your day-to-day work in it. You'll find yourself pining for the "repeat last action" command in other editors in no time!
You asked for good tips to help get past the learning curve on the vi text editor. Many of the previous answers suggest you use no other editors. I think that is good advice. Switching to vi from a more graphical editor requires a change in mindset. It requires thinking in terms of commands, rather than visual changes.
I used nothing but vi for many years and believe the only way you can be productive is to memorize the commands you regularly use. The way I did this was to make a short list of the most common keyboard commands. I grouped and color-coded these commands by function, i.e. Moving the Cursor, Editing, Searching, etc. I was careful to only include the most commonly used commands I did not know. The idea is to create a quick reference that is also an aid in memorization – not to replace the available help screens. Then I printed this list and taped it to the wall behind my monitor so I could see it easily. (The graphical cheat sheets you mentioned might work better for some, but are probably a better reference source than a memorization tool.)
Here's the key. As I became comfortable with one of the commands, I drew a line through it with a pencil. I could still see it if I needed it, but it was symbolic to me that I had mastered that command. That gave me confidence and motivation as I could see regular progress. Once I had most of them crossed off, I removed them and added some of the more rarely used commands. I continued this process until I was satisfied with my command of vi. I knew I had reached that point when I realized I had not crossed off any commands or even looked at the list in a long time.
A couple years ago I had need to work on a UNIX platform where vi was the only editor available. I bought a little pocket reference book on vi, but hardly used it. I ended up making lists and posting them on the wall as I did the first time I used vi. By the end of the first week, I was very comfortable even though it had been five years since I had used vi.
force yourself not. the path to mastery love is.
For me VI is a good emergency editor, but not something I want to use if there is any other alternative available. I realize this is not for everyone though, I'm not saying it's horrid or anything, I just personally prefer a discoverable UI.
But you really have to know VI if you do anything significant in Linux!
So just learn the basics:
i=insert mode
esc=leave insert mode
:wq=save and quit
:q!=don't save and quit
x=when not in insert mode, delete the character.
/=search
That will get you through any editing emergency. There is nothing you can't do with those few commands (and navigation of course). The rest you can "Tack on" as you need them.
Keep a reference or book available though--when you NEED to use VI, you probably won't be able to browse the web--but the man page may be somewhat useful.
You should start with vim (Vi IMproved) and especially its GUI - gVim. The GUI has menus and on Windows you can use the copy, cut and paste shortcuts, so you can replace Notepad immediately. And since the menus display the shortcuts (vim commands) you could learn a lot.
Another thing that you should do from the beginning is to configure vi for your needs. For example, you can transform vim into a Python IDE. By doing this, you'll have no excuse for using another editor, because vi will offer you everything you need.
Every time you're doing a complex editing task, keep wondering if there is a more efficient way to do it. Most times, when it's something that you can describe in simple terms (like "swap paragraphs of text" or "delete everything after the X character in commented lines"), it's something you can do in just a couple of keystrokes in vim.
There are some key features that are extremely useful, and you'll end using all the time. The ones I love the most are:
Block selection (Ctrl-V)
Macro recording (q)
Virtual editing (:set ve=all)
Regular expressions
Piping to external Unix programs
Key mappings
Autocompletion (C-p, C-x C-p, C-x C-f)
The operation+movement combination (this is amazingly powerful)
Ask other programmers what features they find most useful and adopt the ones that fit better your brain. Steal ideas from other people's .vimrcs (here's mine)
delete all other text editor apps.
Then you will have to learn it.
The simplest way to force yourself might be just to remove all the other editors from your machine. Get rid of temptation :)
I wrote a guide to efficient editing with Vim a while back. You may find it helpful.
I'd step back for a minute and ask yourself "why do I want to learn this editor? What makes me think it'll be faster or better than my current text editor?" Then learn those features that will make Vi(m) indispensable to you.
For instance, Vim's CTags integration is completely indispensable for me. I work with a very, very large codebase, and the ability to jump to a function or class definition in one keystroke (regardless of which file it's in) is an absolutely killer feature, one I have trouble working without.
Use your .vimrc file to make macros that automate common tasks.
Your autopilot editor-chooser will pick the editor that will get the job done quickest and with the least amount of mental effort. A little prep-work will ensure that editor is Vim. :-)
EDIT: I've created a flashcard set over at the online spaced repetition site flashcarddb.com, in case you're interested ...
Use a spaced repetition flash card program such as mnemosyne, supermemo, or anki to incorporate learning and retaining new commands into your daily routine. It's not enough to be using vim as your daily editor. To master it, you have to be storing those codes in your head, laying in wait for the time when they're the ideal solution to the task at hand.
Maintain a .vimrc with customizations
Write or edit a vim plugin
Two things that will greatly improve your vi skills:
Practice, practice, practice
Nethack
My suggestion: start small. Just start by memorizing a small set of most useful commands. When I started vi, these were my top 10:
(Esc) to return to command mode (most important!)
a to add text after cursor
A to add text at end of current line
x to delete 1 character
dd to delete 1 line
R to replace text (overwrite)
u to undo
:q! (Enter) to quit without saving
:w (Enter) to save
ZZ to save and quit
A lot of basic editing can be done using only these commands. Once you get comfortable, the rest don't look too difficult.
BTW, I'd like to add that I used to rely on vi for my primary text editor, but now only if I have to. In my case, productivity is better when I use tools like Emacs or Visual Studio (please note: "in my case"). Try more than one tool and choose the one that helps your productivity the most. Good luck!
It sounds silly, but playing roguelike games (such as Nethack or Angband) is a fun way to get comfortable with using the h/j/k/l keys for cursor navigation.
Write down all the short-cuts and features that you use in your current editor while you're using it at work. Then sit down on Saturday morning and using Google and stack overflow find out how to do each one of those in vi. Probably best if you use a sheet (or sheets) of paper for this.
Now disable/delete the other editors at work so that it'll take you longer to find and re-install them than look at your comparison sheet and do it in vi - i.e. you have no choice.
Lastly, publish your list of crossover shortcuts from your old editor to your new one on your blog.
Good luck!
Don't use X11?
$ sudu rm /usr/local/bin/emacs
Change your login shell to vi?
First, force yourself to use ed, then vi will seem like a luxury?
Use the vi key bindings in bash?
Just start using vi all the time?
It seems to me that learning an editor isn't terribly different from learning a language. Immersion works best.
I use vi for really quick edits or when I can't use X11 for some reason, but I live in emacs. Really powerful editors are worth taking the time to learn.
My recommendation is to come up with some simple programs and write them, start to finish, using VI.
Odds are, you will be too frustrated at first by the learning curve to force yourself to use them at work or in any time-sensitive environment.
I've done this before to get familiar with environments/editors, and it works pretty well.
If you are having problems coming up with things to write, I recommend redoing projects you did in school (or anything else that you've done previously). This method has the added bonus of letting you see how much of a better developer you have become. :)
Edit: forgot to mention that you should do this entirely from the console to avoid any temptation to use the mouse!
I remember when I first started learning emacs, it was after I was already very comfortable with Vim, and I was in the same or similar boat that you were, where I knew how to get a lot done in another editor, so as I started using emacs, it was always painfully slow.
However, I think what you'll have to do is just absorb a little bit of the pain, and always, always, ALWAYS make sure that you look up the documentation for doing something that you know you can do in your previous editor, such as moving to the end of a line, or selecting a region of text.
It also helps if you have a local vi-expert on hand that you can ask questions, or if you're like our company, you promote pair programming. That way when you're trying to do something that should be easy, you can simply ask someone, they'll show you how, and if you're using the editor regularly for a few weeks, you shouldn't have to ask more then a couple of times before it becomes second nature.
If you don't have any local resources, there are plenty of books/tutorials/reference sheets online that should be able to answer most of your questions.
Ultimately, learning Vi is like learning other skills, there's no silver bullet, and you'll have to accept that, for a while, you're going to be less productive in it then your current editor. Just keep telling yourself, "Other people have been able to learn Vi, and I'm at least as smart as them" (That's what I tell myself anyway :) )
The main reason for me to use vi is ssh (or Putty on Windows): When you're logged into a Unix server remotely, then vi is always available. And it works with VT100 when neither the cursor keys nor backspace/delete are mapped.
Also having a book like VI Editor Pocket Reference helps greatly.
gVIM has a really good tutorial (link in the Start menu group).
I found working through that helped to get over the initial learning hump; and then switching my Visual Studio to ViEMU helped me hone my VI skills.
Also, the screencasts at http://vimcasts.org/ are great!
You could get your hands on one of the original Happy Hacker keyboards (no arrow keys) and place your (wireless) mouse out of reach each time you start editing.
It's easy to write out a big list of commands/shortcuts, but it's difficult to remember them all without practice.
Focus on one new command at a time. When it becomes automatic, say after using it for a week or two, add another to your repertoire.
You'll be taking the long way around to accomplish certain things in the short term - these are obvious opportunities for new shortcuts to learn.
In my experience it was easier when I tried not to take on too much at once.
My number one suggestion: learn to type fast, without needing to look at the keyboard.
If you can't touch type and are always hunting-and-pecking for the colon or the hjkl or :%s/foo/bar, forget about it. Typing can be faster than using the mouse, but if that's not the case for you, vi's not going to work.
But combine good typing skills, ssh and screen and vi will be natural.
Face the fact that it will create an immediate performance hit. When learning a new tool you need to be able to do something that you know how to do with other tools so the problem isn't your problem. After using the new tool a while it will disappear and you will be only focusing on the underlying problem.
With something like vim (as others have said, vim is vastly superior to vi) it is important to reread and browse the documentation periodically. The interface is completely undiscoverable without it. With each new reading you will see a feature and say, "ah ha, that would have solved this issue I was trying to figure out last week", and will file it away in your brain. Solutions connected to real-world problems that you've had are much easier for you to remember than random shortcuts.
In the end you can use vim with a fairly small subset of it's features, so don't be overwhelmed with all the bells and whistles. Think of all the features in Word, do 99% of the people use them?
ESC gg=G to reindent code and :retab to convert tabs to spaces or spaces to tabs was what hooked me to vim. So actually you don't need to be forced to use it, you just have to learn when it can help you increase your speed.
Go through vimtutor.
Start using vim for simple editing, like config files or html. Learn the commands as you need them.
Search google for a good .vimrc used by someone who uses a toolchain that resembles yours. Turn on syntax highlighting. Find a nice color scheme.
Learn macros because Vim is the best for automated tasks and snippet insertion, like formatting a few words into a complex XML tag or converting a CSV to an HTML table.
You might want to start out with Cream. Cream describes itself as "a modern configuration" of vim. Basically, it is a special version of vim which looks and feels like any other text editor for all practical purposes. But enable the "expert mode" and you have all the power and behavior of vim.
So you can start using Cream as a regular text editor and then experiment with the "expert mode" until you are comfortable enough to fully switch to vim.
Install gVim on all platforms you use.
Then run through the the vimtutor (:help vimtutor or vimtutor at the command line).
Watch the following lecture and follow its advice: 7 Habits For Effective Text Editing 2.0
I say you definitely want to start using it for all your editing. If you fear a loss of productivity then take a weekend to practice it solid (I once did this to switch to dvorak from qwerty and had my productivity high enough by Monday and managed to stick with it after).
It's worth the effort and you won't look back!
Personally, what I had to do was make sure that I could use the Vim key-bindings (or at least, close enough) in several applications. Having to completely switch how I edited text whenever I changed editors made it too hard to get the Vim editing style committed to muscle memory.
In my case, Viemu + vimperator did the trick.