Vim, you complete me
robots.thoughtbot.com
robots.thoughtbot.com
Bret mentions Larry Tesla (starting at about 38:10) who made it his personal mission to eliminate modes from software.
This is the problem I've always had with Vim and I suspect I'm not alone in this. I find the concepts of modes jarring, even antiquated. Everyone who has used vi(m) has copied and pasted text in while in command mode and done who knows what.
Emacs is better in this regard but I find Emacs's need to consecutive key presses (or a key press followed by a command) to be longwinded.
The advantage of either is they're easy to use over ssh+screen (or tmux) for resuming sessions.
That all being said, give me a functional IDE any day. IDEs understand the language syntax. Vim can do a reasonable job of this. Emacs (with elisp) seems to do a better job (or so it appears; I'm no expert) but IDEs (my personal favourite being IntelliJ) just make everything easier. Things as simple as left-clicking on a method and going to its definition.
For statically typed languages (eg Java/C#), IDEs (quite rightly) rule supreme. Static code analysis, auto-completion, etc are just so much better than text-based editors.
Dynamic languages are more of a mixed bag and its certainly the norm for, say, Python and Ruby programmers to use one of these.
Still, give me an IDE any day.
One objection seems to be that people don't like using the mouse. I tend to think the speed differences over not using the mouse are largely illusory.
Anyway, I can use vim but I've never felt comfortable in it and I don't think I ever will and modes are the primary reason.
EDIT: I realize there are plugins and workarounds for many of these things but that's kinda the point: I don't want to spend hours/days/weeks/years messing with my config to get it "just right".
Also, instead of archaic commands to, say, find matching opening/closing braces (which tend to involve an imperfect understanding of the language), IntelliJ just highlights matching braces/parentheses, where a variable is used and so on.
Also, if you use a GUI version of Vim, then it knows about "paste" and doesn't make the mistake of interpreting your paste buffer as keystrokes.
These consecutive key presses ("chords") are just there to provide default bindings and are one of Emacs' weakest points since they're universally horrid. However, there's no single best way to use Emacs[1]: everyone should configure it how they want it to. After years of using my own key bindings I've streamlined them with the rest of my OS[2] and couldn't be happier.
[1] Opposite IMHO to Vi(m) where one should use the default key bindings.
[2] CTRL/CMD-o to open a file, C-s to save, C-f for incremental search, etc.
Another advantage of vim is that most of the time at work I am working on a PC but editing files on Linux boxes. At home I am on a mac. I know I could run X, but I prefer running Putty, and I enjoy the lightweight nature of just bringing up vim. So, currently, vim is my editor of choice.
Also, I must admit that after 20+ years of using vi/vim, I still make the occasional mode mistake and type 'i' when in insert mode, or ':wq', but vim is still my favourite editor.
I guess I could go back to trying to hack together an IDE in emacs or vim with a bunch of buggy, half-supported third party plugins that interoperate poorly if at all, but why?
I've had a quad-core desktop chug under Eclipse (employer required I use it) and still had to fall back to a real editor regularly.
> I guess I could go back to trying to hack together an IDE in emacs or vim with a bunch of buggy, half-supported third party plugins that interoperate poorly if at all, but why?
Well, mostly people use the well-maintained, integrated, and first-party ones instead. Each to his own, I suppose!
If you are using vim, you should play per vim rules. When you are entering text, you enter insert mode. When you are done, back to command mode. Once you have that mental model, you don't try to c-v(or c-shift-v or whatever) in command mode. Also, if you are willing to try vim, grab a vim build with clipboard support and copy-paste from within vim(=+p paste clipboard, =p paste x selection, =+y{motion} copy to clipboard ... in command mode; or ctrl-r+ paste from clipboard, ctrl-r paste from x selection in insert mode)
> I find the concepts of modes jarring, even antiquated.
The thing I like about vim is translating intent to vim commands - delete 10 lines and then move to the top of the file 10ddG, delete everything inside these parens and put me in insert mode cib etc. Without modes, these won't be as short and sweet. You will be left with long key combinations - the way emacs does it.
> Emacs is better in this regard but I find Emacs's need to consecutive key presses (or a key press followed by a command) to be longwinded.
Isn't that obvious? If you always want to be in insert mode, how else will the special instructions be entered?
> The advantage of either is they're easy to use over ssh+screen (or tmux) for resuming sessions.
And they are very good at editing text, and majority of programming languages, though might require some configuration.
> For statically typed languages (eg Java/C#), IDEs (quite rightly) rule supreme. Static code analysis, auto-completion, etc are just so much better than text-based editors.
I generally am able to find something for Vim which makes language specific stuff easy.
Clojure - http://www.vim.org/scripts/script.php?script_id=2501 Java - http://eclim.org/ Go - https://github.com/nsf/gocode C - http://www.vim.org/scripts/script.php?script_id=3302 Python - http://rope.sourceforge.net/ropevim.html
And a lot more...
> I tend to think the speed differences over not using the mouse are largely illusory.
Doesn't that depend on the task? What will be faster - ctrl-f on this page or clicking edit(or some menu)->find?
Also, for me, it is more about having my fingers on home row is the sweet spot and moving my fingers from my sweet spot is irritating.
This issue is that studies show us vim's rules are wrong: modal editing is a source of confusion and error. I used vi[m] exclusively for 8 years or so and until the very last day I could still make major modal based errors.
The so called studies show people who aren't used to modes are confused when using a modal editor.
> I used vi[m] exclusively for 8 years or so and until the very last day I could still make major modal based errors.
I have been using vim exclusively for 5 years now. And I stopped making modal based errors after 2 weeks. My anecdote cancels yours?
From what I have seen, people who leave vim in insert mode are the ones making mode errors. Insert mode isn't the rest mode for vim, normal mode is. You are bound to make errors when starting because out of habit, your mind assumes insert mode as the rest state.
"Don't listen to this study, listen to my firmly held belief". That's not how this works. If you want to combat a study you need to do so with another one, not by just saying throwing out untested assumptions.
>From what I have seen, people who leave vim in insert mode are the ones making mode errors. Insert mode isn't the rest mode for vim, normal mode is. You are bound to make errors when starting because out of habit, your mind assumes insert mode as the rest state.
Thanks for the condescension. Have you ever started to type a word and had your hands just finish it for you? Sometimes there will be some relatively large word that I type out commonly enough that when my hands notice the first few letters of it they'll type it out automatically with me having to go back and delete it and type out the similar starting word I meant to write. I even recall having my hands do it again on the correction once.
Having this kind of muscle memory is a killer for vi usage. Lots of times I have intentionally left the editor in insert mode for just a second while I grab some text from, say, a website to paste in. What I didn't realize is that my hands knew to always get back to command mode when changing screens so even though my mind had tried to save keystrokes my hands defeated me. The result? Pasted a huge document into command mode. Great. Similar sync issues came up regularly enough that I typically mashed Esc 2-4 times (in case there was, e.g. a command active that would write in the Esc char) rapidly before starting anything to ensure that I was where I thought I was.
In my experience, I wouldn't get the time savings I should have been getting due to having to slow down for the mode management.
Yeah. Combat the studies that you totally provided the link to. Throwing claims around saying "scientists say that" or "studies have proved that" is surely not how it works.
> Thanks for the condescension.
What part was condescending? Leaving vim in insert mode causes errors? The rest state of vim is normal mode?
> Having this kind of muscle memory is a killer for vi usage for you
You are extrapolating personal anecdotes to absolutes.
Also it occurs to me that I may do some of those things like mashing esc repeatedly just to be sure subconsciously.
You can just show that the methodology is flawed, no need to repeat the experiments in all cases
If using vim is wrong, I don't want to be right.
Honestly, I can believe such studies, and I still would use vim.
One, my shoulder gets tired and sometimes hurts if I move back and forth between keyboard and mouse too much.
Two, by the time I move to the mouse and back, I could have done the equivalent twice on the keyboard and moved on.
Three, there is nothing sweeter than "How did you do that?" :)
>Two, by the time I move to the mouse and back, I could have done the equivalent twice on the keyboard and moved on.
Vim got this part right, and it ends up being better than Emacs in that regard: in Emacs you also don't need the mouse but all the chording requires moving the hands too much. Ideal would be to take Emacs' non-modal editing and combine it with Vi's simply edit mode: for example, say you are in "command mode" only if you hold down Caps lock, but when the button isn't held down the editor is always in insert mode.
try to set mousemode (vim) if vim is compiled with x11-support.
Staying late one night to finish an assignment that was due at midnight, you happened to catch a glimpse over one of the quiet uber-programmer's shoulders. Your eyes twinkled from the glow of rows upon rows of monitors in the darkened computer lab as you witnessed in awe the impossible patterns of code and text manipulation that flashed across the screen.
"How did you do that?" you asked, incredulous.
The pithy, monosyllabic answer uttered in response changed your life forever: "Vim."
At first you were frustrated a lot, and far less productive. Your browser history was essentially a full index to the online Vim documentation; your Nano and Pico-using friends thought you were insane; your Emacs using friends begged you to change your mind; you paid actual money for a laminated copy of a Vim cheat sheet for easy reference. Even after weeks of training, you still kept reaching for your mouse out of habit, then stopped with the realization that you'll have to hit the web yet again to learn the proper way to perform some mundane task that you never even had to think about before.
But as time went on, you struggled less and less. You aren't sure when it happened, but Vim stopped being a hindrance. Instead, it become something greater than you had anticipated. It wasn't a mere text editor with keyboard shortcuts anymore—it had become an extension of your body. Nay, an extension of your very essence as a programmer.
Editing source code alone now seemed an insufficient usage of Vim. You installed it on all of your machines at home and used it to write everything from emails to English papers. You installed a portable version along with a fine-tuned personalized .vimrc file onto a flash drive so that you could have Vim with you everywhere you went, keeping you company, comforting you, making you feel like you had a little piece of home in your pocket no matter where you were.
Vim entered every part of your online life. Unhappy with the meager offerings of ViewSourceWith, you quickly graduated to Vimperator, and then again to Pentadactyl. You used to just surf the web. Now you are the web. When you decided to write an iPhone application, the first thing you did was change XCode's default editor to MacVim. When you got a job working with .NET code, you immediately purchased a copy of ViEmu for Visual Studio (not satisfied with the offerings of its free cousin, VsVim).
Late one night, as you slaved away over your keyboard at your cubicle, working diligently to complete a project that was due the next morning, you laughed to yourself because you knew no ordinary programmer could complete the task at hand before the deadline. You recorded macros, you moved entire blocks of code with the flick of a finger, you filled dozens of registers, and you rewrote and refactored entire components without even glancing at your mouse. That's when you noticed the reflection in your monitor. A wide-eyed coworker looking over your shoulder. You paused briefly, to let him know that you were aware of his presence.
"How did you do that?" he asked, his voice filled with awe.
You smile, and prepare to utter the single word that changed your life. The word that, should your colleague choose to pursue it, will lead him down the same rabbit hole to a universe filled with infinite combinations of infinite possibilities to produce a form of hyper-efficiency previously attainable only in his wildest of dreams. He reminds you of yourself, standing in that darkened computer lab all those years ago, and you feel a tinge of excitement for him as you form the word.
"Vim."
:wq
It is exactly how it happened to me. I looked over shoulder of one guy and when he changed some code in front of my eyes before I could blink, I asked him 'How did you do that?' And rest is history.
I look forward to being one of these novices. I'm faster in vim than any other editor by far, but I know I could still be 2x faster.
I've got a quarter century history with vi and its kin, and am still learning new tricks.
One time I had to do a college project in a language I had not used before, JESS (JRE cousin of CLIPS). Though its similar to Scheme in which I had coded a few years before, it has a few of its own syntactic idioms. I planned to do the project in VIM. As there was no baggage of using JESS with any IDE before, there was no such thing as a hindrance or inhibition which I used to have while trying to using VIM for coding C/C++, etc.
Within the next 2-3 weeks I learned the basics and a few intermediate use-cases of VIM (refactoring using registers, etc...). After finishing the project, I shifted to code in C/C++ using VIM has my primary editor and have never looked back since. I basically piggybacked my experience with VIM in JESS and the it took less than a day to translate all that and use it with C/C++ code :)
With regards to ViEMU, my use case is to open the same file in both VIM and Visual Studio quite sometimes as they both can detect changes made to the file outside of the editor. So far its worked without any issues :)
http://stackoverflow.com/questions/1088387/what-specific-pro...
After a couple of months, he got used to enough Vim functionality to make the jump. He was also motivated by the vim-features lacking in Sublime Vintage mode, but I can't recall which ones specifically were missing
Stay classy.
i
Hi, Just want to say thank you for this beautiful note.
:wq
$sendmail <Rudism's mail> < thanks.txt
PS: had you provided the email in your profile. I might have actually mailed you :-)
(no need to hit <Enter>)
(no need to quit Vim ;-)
(Never ever leave vim)
;)
I think the best thing about Vim is that it will always keep surprising you. If only we could find a life partner like that, there won't be any divorces.
> If only we could find a life partner like that, there won't be any divorces.
Personally, I find that if you stop relying on your life partner to be the person you expect them to be or want them to be, then there won't be any divorces. This idea that you have to just find the right person and everything will be fine is pretty flawed and won't take you far. Sure, people are different, and you should find a good person you can get along with, but that's only the start. Any person will stop surprising you after a while, and you have to be prepared to start from there and still build something together. In other words, don't give up just because your partner is an emacs user.
In CSS, <C-x><C-l> is a gift of the gods.
But I guess I just don't get it. It's too obtuse. I don't feel connected to my editing while using it, I feel... connected to Vim. Which, I think, might explain why others feel so connected to Vim too. They get attached to it because it's an investment, and as we know from various psych studies, we get attached to things we invest in.
This isn't a bad thing, just wanted to throw my 2¢ out there. Vim's a cool language for text editing, but it's not the only one.
For me and others, we actually feel connected to our text instead of Vim. Let me give you an example, let's say I have following sentence.
"Why, oh WHY, do those #?@! nutheads use vi?"
my cursor is on the letter 'h' of 'nutheads'.
Let's say I decide to change the whole word to 'crazy people'.
Here's how you would do it in conventional editor (using EditPlus as an example).
Ctrl + <- (to jump to n)
Ctrl + Shift + -> (to select the whole world)
Shift + <- (to remove the space which was selected. )
Type in "crazy people"
Here's how you would do it in Vim.
ciw - (change inner word), it gets rid of the whole 'nutheads' word and puts me in INSERT mode.
type in "crazy people"
As you can see, EditPlus forces to you to navigate the text using conventional method. It doesn't have a concept of a 'word'.
Compare this to Vim. I told Vim what I exactly wanted to do ('change inner word') and it let me achieve that without any fuss.
As I wrote in my other comment, Vim lets me 'talk' and 'interact' with my text at a semantic level. Vim is like a translator which completely disappears when I am working with my text.
The example sentence was borrowed from another excellent article on Vim:
It's important to note that many modern text editors do have concepts of "words" and "lines" and such that can be used in similar ways. Granted, not near the extent of Vim, but they're still useful.
In sublime for example, I can Ctrl+Shift arrow to select words before and after. This even works with multiple selection (multiple caret positions). It's pretty cool.
Again, I understand that Vim is more of a language to describe editing text and is very efficient, I'm just saying you can get close with modern editors, and personally I find their visual language to work better for me.
- up to a specific character?
- up to a specific string?
- up to the beginning/end of a document?
- up to the beginning/end of a sentence?
- up to the beginning/end of a paragraph?
Good luck ;-) Maybe these examples are lame because I haven't edited text in a while and I couldn't think of anything better, but I hope you can see what we are talking about.
Read PG's essay about Blub languages and Lisp, then replace Blub with mainstream editors and Lisp with Vim and you'll understand why Vim is better. My colleagues used to ask me why I kept using a weird editor, and when I answered they replied the same way you have done, yet they always marveled at me editing texts at insane speeds. Go figure.
With Vim, you also have a reduced mental load, as its command set relies on intuitive and flexible composition.
Actually I don't even use Vim. I use a Vim mode for GNU Emacs, which gives me these added advantages: - learning a Lisp (ask Eric Raymond why this is advantageous); - having a powerful batch text processing tool (no need for Perl, Awk, and the likes); - a box of tools for several tasks which are more powerful than mainstream ones.
Have fun.
I personally know and like Vim and Emacs, but I'm using ST2 because those editors lose some of their greatness on vanilla Windows. And Emacs keybindings do hurt my wrists.
Also, I could never get really fast at editing multiple files inside a single Vim session. Nothing near Emacs with ido.el or vanilla ST2. I already tried Lusty* packages and Nerd* packages... It's also kinda hard to prevent :q from quitting the whole editor, which always bugged me.
When I open it from the terminal for a quick fix on a single file, Vim works very naturally and I think, once more, "hey that edit was easy and fast - why not switch to it as my main editor?"...
The only reason you are using another editing model is because you've found the tools offering Vi-style editing to be lacking in important areas.
Sublime may be better than Vim as an overall editor in your particular case even when the editing model of Sublime is less efficient than the one of Vim. We agree on this: we don't live in a perfect world. Indeed, even Vi-style editing is not perfect, as it was designed for a different keyboard than those which are commonplace nowadays.
I'm curious though: I thought it was Emacs that had a special keyboard in the old days. What do you think could be easier in Vim with a different keyboard? (I can only think of ESC position).
Religious war nonsense. Vim still uses modal editing, which we've known to be a mistake for how many decades now? Sure, vi is better than Notepad. Congratulations.
>Could it be that studies about modality were flawed? I think so.
This isn't how we progress. Do you have a study that demonstrates the opposite? Then claiming the study was flawed is meaningless.
>And I had an hard time using Vim before being told how to use it effectively.
Stay classy. I knew how to use it just fine, but mode management slows everything down.
I couldn't find any. Could anyone provide some pointers, please?
> I'm talking about modal editing. Obviously I'm not against context.
When scientific proof lacks, appropriate analogies can be our only tool in analyzing a issue and reaching a conclusion. My point is that people don't seem to have issues with modality in other contexts, provided that they know how to cope with it, thus why should I doubt their ability to cope with modality while editing?
> This isn't how we progress. Do you have a study that demonstrates the opposite? Then claiming the study was flawed is meaningless.
Sadly, progress is slower than we wish. If a study contradicting empirical evidence is flawed, it doesn't prove anything, for empirical evidence wins and we are back to square one.
> I knew how to use it just fine, but mode management slows everything down.
This proves that some people have issues with modal editing. Why? Maybe: - they didn't approach it effectively (in the case of Vim, they lingered in Insert mode); - their tools were inappropriate (in the case of Vim, the Esc key was too far). - or modal editing requires some mental capability which not everyone possess (some people can type on Dvorak and Qwerty, indifferently); - or modal thinking is a learned skill; - or... If we can solve this problem, instead of saying that modal editing is better, we could say that modal editing is better when some conditions are met.
EDIT: I've also thought about reasons for Vi-style editing not being as superior as it was in the past: - keyboard layouts do not resemble the keyboard layout used while designing Vi; - keyboards with integrated touch-pads and/or track-pads are available to make switching to a pointing device quicker.
GP highlighted this special thing. I guess you missed his main point.
Not to get into a holy war, but that's is one of the things I don't really like about Vim—the community is pretty religious and Vim "can do no wrong" in a sense. The process of conversion is just an epiphany and if you haven't realized that, then you must just not have used it enough, because it's factually better. Not really true. I'll leave it at that.
Your original comment was exactly how I felt when I was learning Vim. I also thought that Vim is obtuse and it gets in my way. And now after using Vim for over 3 years, I now know why Vim is the way it is and I was sharing my epiphany.
By all means, use the editor which makes you most productive (you are already ahead of 70% folks who don't even care to find better editor). But at the same time, if you think that Vim is crazy, at least listen to the other side of an argument with an open mind.
PS: I also replied to comment by 'recursive' on the Ctrl + D shortcut.
I compel you and anyone else who is quite dogmatic about their choice of editor to try explaining it in such an objective, non-patronising way, so that the layman can think, "oh, it sounds like it's worth learning then."
I'm not a Vim user per-se, but I'd find more value in something like this, possibly with a more specific follow up:
Vim works a bit differently than other editors. It cares more about manipulating existing text than creating new text, and so it tries its best to let you make changes without just deleting and re-typing from scratch, or using your mouse to point and click and drag and highlight.
It has a steep learning curve so it's initially hard to adapt not just to this change in perspective, but also to the commands and shortcuts that allow you to be more efficient and productive.
Such is the investment of time and effort required to do be good in it, you might consider grokking Vim a commitment as big as grokking your programming language of choice. However, you will in return acquire a life-long knowledge of working in Vim, and using it will become second-nature and infinitely preferable to manipulating text by hand.
As a developer, knowledge of Vim is valuable because of two things:
1. Portable configuration: what you learn, and how you personalise your editor, is transferrable to other machines, as it's just text. No modern editor has adequately replicated such basic functionality.
2. Ubiquity: you can't load Sublime Text, Textmate, Eclipse, {$gui_editor} on the VPS you routinely SSH into. You will, however, have access to Vim, or its predecessor Vi. You can thus have a somewhat familiar environment when working on remote servers, without any faff.
Only if you don't know how to use it. Ctrl + D does it in fewer keystrokes than you can in vim.
Let's say your sentence was like this:
"Why, oh WHY, do those #?@! 'nutheads' use vi?"
[Notice that word 'nutheads' is enclosed in single quotes.]
If I am on the letter h, I can press [ciw] to only replace nutheads word with my target word, it will keep the single quotes as it is.
OR
If I wanted to replace the whole word including the quote, I would press [ciW] (notice the capital W)
Now, can you use that knowledge of Ctrl + D in this situation in Sublime?
Yes, in the second case, Sublime is one additional keystroke. I know you could come up with examples that would show bigger advantages for vim.
FWIW I do believe that vim has advantages to some editors in certain scenarios, but I think those advantages are overestimated by the vim-inati. If you've spent years learning one editor, of course it will seem more capable than editors you have used less.
AFAIK, Sublime Text 2 doesn't provide a shortcut for that. You can do Ctrl+D to select "called" but then what? Extending selection to scope or brackets won't help and you are back to a series of Ctrl+Left -> Ctrl+Left -> Ctrl+Shift+Right -> Ctrl+Shift+Right -> Ctrl+Shift+Right. In Vim, that's ci', or ca' if you want to also remove the quotes. Hell, you don't even have to move the cursor to the quoted text to do that.
This scenario happens dozens of times in a given day around here and, as for many other little things, Vim and his "awkward" language and it's "antiquated" modality rule.
The irony, here, is that you actually can change the content of a pair of quotes in ST2.
If you activate its Vim mode.
That's not to say Vim doesn't have an excellent ecosystem, and has tried and true ergonomic benefits, however I feel that if someone spent the same amount of time learning, say TextMate (just an example, may not be the best), they would be just as productive.
In other editor you have keyboard shortcuts and there are only so many you can have. In VIM there are over 1500 commands (not shortcuts). People who say "vi key bindings" or "vi shortcuts" don't get vim.
You have 'v' for visual mode, where you move the cursor around and can select stuff.
You have 'd' to delete things.
If I press 'v' then move around, then press 'd', I'll delete the selection.
If I press 'vf,' it means 'select until you are on a comma'. If I press 'df,' it means 'delete until you are on a comma'.
The problem with these two modes is that they're restricted to one line.
Now if I do 'v/,$', it means 'select until the first match of the regular expression ',$' (comma on end of line). If that comma is 5 lines below, it'll find it.
What's fun is that with this sublanguage, I can say 'dv/,$' and it will delete where the selection of the next comma at the end of a line, or more generally, <Command>v/<Regex> will do the command until a given regex. If I replace 'd' with 'c', it deletes and puts me in insert mode ('c' is change), and so on.
Even nicer? what if I'm writing Erlang (I usually am), and I want to delete, say 3 functions. I could delete one by getting to the beginning of the function and delete until '\.\n' as a regex (functions are terminated by a full stop). So the command becomes 'dv/\.\n' for a single function.
Rather than calling the same command 3 times, I can do it once, then press '.' twice to repeat the previous ones.
Or I can use the fact that vim has this sublanguage and instead call '3dv/\.\n', which will delete until the next end of a function (full stop + line break) 3 times.
Its command set is fully composable and at some point you find your sweet spot in there.
You have just built your own Vim.
Vim is like this but without having to take your hands off the keyboard, so you get a little extra. But using the mouse and having a very visual hand-eye-coordinated text editing representation is really intuitive, so it's definitely a tradeoff.
Vim takes a long time to get used to, is not intuitive, and gives an extra boost in speed by its very nature; pretty much comes down to that.
Sort of like a car: it takes a long time and investment to learn how to drive and get used to the completely new world of streets and driving rules, but once you're there you can get places way faster.
All that said, I still use SublimeText, because I don't necessarily need Vim to program efficiently (I admit, my main obstacle is my mind, not my editing speed), and the experience of SublimeText is very efficient and matches my intuitive mental model of text. So the moral is, use what works for you.
Example 1: TextMate users create bundles that drop in common boilerplate easily, and they have a really nice ways to jump between files in a large project. Vim users mostly don't do either of those.
Example 2: IDE programmers tend to have syntax-aware tools that implement common tasks like "extract local variable" or "jump to implementation". Vim versions of these tend to be crude approximations that use regexps instead of actually parsing files.
Personally, the cost of typing more slowly and having to use a mouse to edit text means that I haven't ever learned to use modern editors effectively - so I'm faster as an expert in Vim than I am as a novice in Eclipse or TextMate or IntelliJ or Sublime - but in many situations an Eclipse expert is probably faster than me.
http://www.vim.org/scripts/script.php?script_id=2715 http://www.vim.org/scripts/script.php?script_id=1984 http://eclim.org/
Picking up Android development is the first thing that really made me consider switching out of vim. With eclim, I'm now half in half out. I do most of the actual coding in vim with eclim doing the menial work of basic error checking, automated imports, automated refactoring, etc. For debugging, and some of the layout tools I'll switch to the Eclipse instance that's already backing eclim and do it there. It's a nice compromise.
I've used it non-stop from late 2006 to late 2010 and I can attest that the last three years were extremelly boring. On the other side, 2 or 3 months is the time needed to have a firm grasp on the basics and, after 1 year and half, I still learn new tricks every day.
If you want inherent advantages, don't look further than Vim's modes and its language.
My startup Circle is written in Clojure, so I was pretty much forced to learn Emacs, and the world is such a nicer place. I really wish I had learned Emacs 5 years ago - with the time I spent mastering and then trying to customize vim, I could have mastered and learned to properly customize emacs.
It'll let you use <Tab> for all the completion types, and you can tell it the fallback order for various thing (i.e. try omni, then <C-N>, etc.). It's even slightly context aware, so it can guess a good first completion method for you.
All with <Tab> :)
This article is very incomplete, there are various completion modes. I also don't recommend mapping complete to tab (or even using SuperTab or other completion plugins). Vim has a total of 13 different completion modes (see :help ins-completion), all of which are useful. There's complete on local and global keywords, complete for complete lines or filenames.
In particular, this article calls Vim 7's omni complete (^X^O) "syntax aware complete" which it is not. It's a language specific completion, which can complete stuff like members of structs or functions. You need your language specific plugins to be installed. Vim ships with a decent plugin for C and C-like languages, which works if you have a ctags database generated (:help 'tags').
If you want syntax completion, you can map it to user-defined completion (^X^U) like this: set completefunc=syntaxcomplete#Complete
It's not particularly useful as such, because syntax complete completes keywords like "for" and "while" which we all have in muscle memory.
It might be due to my vim configuration but I doubt it (though I am not a vim script expert by any means).
Here is a function I found on the web a long time ago and that seems to prevent that problem:
inoremap <Tab> <C-R>=MyTabOrComplete()<CR>
function MyTabOrComplete()
let col = col('.')-1
if !col || getline('.')[col-1] !~ '\k'
return "\<tab>"
else
return "\<C-N>"
endif
endfunction
Credits/source: http://www.slideshare.net/andreizm/vim-for-php-programmers-p... slide 44
edit: formating and credits
I took snapshot from my current editing session:
Selecting the last item:
Selecting the second last item:
My vimrc is here: https://github.com/SolutionYogi/VimSetup
I think you should experiment with some other color scheme or try to tweak your existing scheme.
In Vim you have to specify whether the word you're looking for is above or below the cusror (using C-P or C-N). IIRC, TextMate just looks for the closest matching word, no matter where it is.
I wrote a little plugin to do make it exactly that:
https://github.com/sirdavidoff/vim-nearest-complete
Disclaimer: totally rough and not (yet) very customisable
In HTML5, you can. See http://html5doctor.com/block-level-links-in-html-5/
And isn't it the job of the programmer to know those things?
in intellij, you can ctrl+w to select word, ctrl+w again to select statement, ctrl+w again to select function, etc.
you can also refactor replace all, shown if foo.gif actually exist in img src, ctrl+click to css, shown if a variable (in code/js/css) is unused, hinted if a line can be simplified, etc.
can vim do that?
if it can not, what's the compelling reason for people like me to use it? (i honestly interested, but wondering if it's worth the effort)
IMO the main advantage of vim is it's instant. No waiting for the IDE to load. IJ takes quite a while to load and you have to have your project set up.
Another major advantage of vim is it's available everywhere. SSH to your production server and edit just like you do your code.
But I have to say: I much prefer coding in the Jetbrains editors. They offer a UX that can't be matched by vim. They are just smarter, esp for statically typed language. But even dynamic - they are damn good. And you can use VIM key bindings if you like.