Don't ever start using vi. After you do, any text editor that you are forced to use that doesn't have vi key bindings will give you fits and make you cry.
Learning vi is your standard process of enlightenment and elation followed by a lifetime of disappointment. Think about how you'd feel if you ate the best meal of your life at age 13, and the restaurant where you ate it went out of business the next day.
You'll be frustrated by all other software. You'll wander around trying to explain to other people why the thing you had was so good, and it was so easy, and that nothing else compares, and wouldn't it be great if everyone did things this way.
I learned the bare minimum required to use vi. Insert, find, override-save... That's pretty much it. When vi is the only option, it's good enough; otherwise I'm free to use different editors.
Funny that you got downvoted. The entire industry has spent the last... forever years making things easier to use/gui-fied, and you get dinged for wanting to use those improvements.
The goal of a new text editor shouldn't be to make things better for people who are already experts on an existing platform. It should be to make it better for beginners on the new editor (because initially, everyone is) and better for them when they become experts.
Saying "I'm an expert at vi, and other editors don't work as well for me" is a pretty meaningless statement. Of course they don't. It's like saying "I speak English, and I find speaking Spanish really hard, so English must be the best."
I think this is a case of not being able to have your cake and eat it too; you can make something easier to use, but it usually comes as a compromise to more expert users because you have to simplify the interface, remove functionality, reduce configuration options, etc. Conversely, adding more power will usually mean increasing the difficulty for beginners; if you require that users are comfortable with using a semi-programming language to write configuration files, you get more options and more power than you could via a simple and straightforward gui.
In the end I don't think either approach is better, just different. To address your first statement, I think editors can either choose to become better for experts in a particular domain, or they can choose to be easier to learn for beginners, or some compromise between the two. I have yet to see an application that manages to do both.
I agree that someone's subjective opinion of editors other than the one(s) they use is not very useful, but i don't think that was the point of the post you replied to. He was simply stating what I stated above; an app that is good for a beginner is not necessarily the best for an expert, and in the end you have to find some compromise between the two.
EDIT:
For the record, I think vim has a pretty good learning curve; vimtutor is great, and you only really need to know the most basic parts of modal switching for gvim to be used like any other text editor. Once you gain some mastery of things like movement command, macros, markers, etc. you can really start to accelerate your workflow. I'm not one of those people that started using hjkl from day one.
I'm actually quite satisfied in being a perpetual "vi beginner". With regard to Linux however, I started using it (professionally too) before most people (including IT professionals) heard of it at all. I enjoy puzzling my coworkers by declaring that I am "vi-ignorant and proud of it". :)
Anyway, I guess I just dislike vi because it's different from everything else. I like things that are uniform. That's what really saves a lot of time and effort in the long run.
On servers, I only require a few simple things of the editor; for everything else, there's always the command line or one of the P* scripting languages. On my laptop, I can install anything I want. Never saw the point in wasting time to learn an arcane editor from the '70s.
It's not impossible to make tools that are easy for amateurs and powerful for professionals, but empirically it's rare.
The reason is pretty simple. Take any tool, like Notepad, and start making it better for professional usage. Pretty soon it's full of features and shortcuts that help professionals and confuse amateurs.
It's as it should be though. It makes good sense for professionals to spend more time upfront learning more powerful tools because the savings over their career will be massive.
The amateur won't see any benefit from spending a lot of time learning if they only use the tool for a short period.
Don't ever start using emacs. After you do, any text editor that you are forced to use that doesn't have emacs key bindings will give you fits and make you cry.
Learning emacs is your standard process of enlightenment and elation followed by a lifetime of disappointment. Think about how you'd feel if you ate the best meal of your life at age 13, and the restaurant where you ate it went out of business the next day.
You'll be frustrated by all other software. You'll wander around trying to explain to other people why the thing you had was so good, and it was so easy, and that nothing else compares, and wouldn't it be great if everyone did things this way.
As someone who used emacs for 8 years, then swiched to vim and used that for 4 years, and then switched back to emacs 2 years ago -- my personal experience is that being forced to use anything which isn't vim or emacs will give me fits and make me cry, but switching from one to the other is mostly fine.
As someone who always used graphical text editors with discoverable interfaces, for a long time I found both vi and emacs to be like black boxes covered in unlabeled fiddly knobs — except turning vi's knobs in the wrong order would make some of the other knobs start spinning wildly. Just trying to get either of them to use a color scheme that didn't hurt my eyes was an exercise in frustration. I can use either passably nowadays and do use both fairly frequently, but I have to admit I still find don't find either particularly nice to use. I feel like whatever is great about them is always hidden somewhere just out of sight.
As someone who has used vim for many years, tried emacs a few times and was confused and disheartened, and continued to just use vim, I can provide no useful anecdotal evidence.
That's because the Emacs comment missed Emacs's greatest feature: elisp. Adding functionality--even fairly complex functionality--to Emacs is much easier than extending any other editor I've used. Here are a couple of great examples from the last week for me:
I am currently taking a compiler course where we are implementing a particular language not entirely unlike--but not entirely like--Lua and Python. As part of the process, we need to churn out quite a bit of test code. Naturally, Emacs does not support this language by default because this language only exists as an implementation exercise for a couple of projects; however, creating a useful mode that does syntax highlighting and indentation--basically all you need to program comfortably--only took about 100 lines of code and less than an hour of programming!
Apart from my studies, I also work part-time at a startup. As part of this, I have to use and maintain a bunch of remote AWS machines that do all sorts of things: hosting, continuous integration, staging... I noticed that I was opening a lot of shells both locally and remotely. Writing up a command bound to a global key-stroke that prompts me for a name, opens a shell in the current directory (including remote directories!) and sets the prompt of the shell to its name literally took five minutes. And now I've saved a lot of time managing all my shells.
Being able to make my editor do exactly what I want with a trivial amount of effort is magical.
The deciding factor for me is that I can use the same basic Emacs keybindings in any other text entry widget, so my most central muscle memory translates to the shell, XCode, Firefox etc.
I set up most of the emacs/OS X bindings in insert mode as well, and slowly migrated away from them toward more use of vim features. It eased the transition, and now I don't really feel any mismatch between the two.
Hehehe, yes I keep opening printer dialogs and new windows in my browser because of this. Though to be fair, that's often more due to being on Windows and not having 'focus follows mouse'.
I think a lot of other editors (even in Visual Studio, Netbeans, Eclipse) have emacs keybindings though, so the situation is much better for an emacs user. It is much easier to implement due to modelessness of emacs.
Maybe you didn't use Vim with much depth? I know plenty of people who claim to use it but just stay in insert-mode all the time, don't use text-objects, etc. It doesn't really count if you actively avoid most things that make vim unique.
Maybe you shouldn't assume that people are morons?
---
Clarification, since I'm getting downvoted for that: Go look at the guy's profile, and his blog. He's an experienced dev, using vim for "6 years", and he's been on HN for three, has racked up a bunch of karma, blah, blah, blah. I'm pretty sure he got past the "use vim as notepad" stage. Assuming that he hasn't is assuming that he's a moron, and contributes nothing to the discussion.
How about you deal with the meat of what he's said? Something like "vim can do this thing which emacs can't" (unlikely) or "emacs does this annoying thing which vim doesn't" would be more productive than "Hey, I'm going to assume that you know nothing about vim, despite you using it for six years"
Actually, that's more of a rant than a clarification, but I'll let it stand.
Interesting; This comment has been voted up and down since I posted it, but nobody's yet answered with something that makes vim more annoying than emacs (or vice versa).
Well, I use Xcode because the performance loss in writing Objective-C without autocompletion is larger than the performance gain from using vim. However, navigation is just so painful, and "awful" is really being kind about Xcode's find/replace.
quick lookup and a quick find as you type function. I like that if you press delete it will lookup the scope prior. so like if you type "addobj" and then delete a few times to "add" it will show you all the add commands again. Probably standard fare but not all implementations get this right.
Install was painless and I was able to map the invocation to ctrl-space, probably a better way to do it but I did it in a few seconds without looking anything up:
> Do whatever you want. Don't learn it if you feel it's too much effort just for nothing. Learn emacs instead. Or stay in your IDE using a lousy editor. Whatever.
Why do all articles about how wonderful vi is end with condescension?
Anyway: vi -> fast editing. IDE -> fast maintenance. I know which one I'd choose. The text editing features of an IDE is not why people choose to use IDEs (note: of course this helps best if you use a well-supported statically typed language - a Ruby IDE can't be as awesome as a Java IDE).
Also, there could perfectly well be good IDEs with good Vim key binding support. This would be a wonderful mix of two worlds, and finally end this stupid discussion. I believe at least Qt Creator has a half-decent FakeVim mode baked in.
"Why do all articles about how wonderful vi is end with condescension?"
Because one way to get someone over the initial learning hump is to "encourage" them by challenging their manhood. Same principle behind a boot camp sergeant telling every single incoming group that they are the worst bunch of nambypamby girliemen he's ever seen and he's been in this army for 25 years and that he will consider it a personal failure if he doesn't cause each and every one of you to quit in a crying mess. You're supposed to be motivated to try your best in the hope that he'll begrudgingly concede at the end that you didn't suck after all.
It works, but it has the side effect of creating a strong tribal identity among those who pass the bar, an "us" who are good enough to make it and the "them" who didn't. The military deliberately exploits this side effect; I'm less convinced it's a good idea in a programmer context.
My response to this approach has always been the middle finger. If someone can't afford me even the minimal level of respect, I'll leave. My worth is not dependent upon what other people think.
I don't see the above quote as particularly disrespectful in context. It's a bit like a friend who has just spent half an hour talking you into going for that new wonderful job, and says 'or you could stay in your crummy current job'.
Basically he's saying: "I think this way of doing things is awesome. Here's how to do it my way. Your way of doing it is crappy compared to mine, but hey it's your choice to continue being a substandard performer."
Even your example is riddled with condescension, with your judgment from on high that your friend's job is "crummy". It's not only disrespectful; it betrays an unsavory vanity on your part.
If your worth is independent of what he thinks or says, why not listen to him and make decisions based on the merits of his argument instead of letting the emotional content throw you off? I'm not saying I'm capable of doing that, just that it's what I'm striving for. :)
I'd still listen to what they have to say, but I'd consider it to be untrustworthy information, as their insult against those who do things differently would tell me that they have a strong enough emotional investment in their decision that they're unable to rationally consider the alternatives.
Either that or they're being manipulative, which is also a big red flag.
Comparing vi to an IDE is like comparing a screwdriver to a fully automated car assembly line... it is completely beside the point and they each have their purpose and downsides.
The point is: these comparisons always try to make vi seem like the always better choice INSTEAD of an IDE and this is were I completely disagree. And you make it look just like that with adjusting the comparison in favor of vi, the screwdriver. This is just wrong. Let's see, you could also say:
Screwdriver: specific to only one type of screw, limited to only a couple of similar sizes and all you can do is drive screws in and out or maybe stab someone.
Assembly line: way more complex and needs some setup time but you can do WAY more things with it, way faster, way more efficient once setup, especially on a larger scale. It can drive screws in and out, solder, cut, fold, package etcetcetcetc. Pretty much anything you set it up to.
So, vi is a horrible replacement or alternative to use in the typical huge Java (or what have you) e.g. web app projects where things like auto completion and easily getting from one class to another, built-in compiling, debugging, refactoring, source control etcetcetcetc really start to make your life easier. vi on its own cannot offer you that, not even remotely... then you need a shell and other programs to do all that. And there are no alternatives to most of the tasks an IDE can offer you help with.
vi is definitely nice for editing files especially on a slow line and as a general purpose editor - but it is no replacement for an IDE and the comparison that it is "better than an IDE" might only apply for exactly one task: editing files. IDEs offer you tons of other things. So it is just wrong to compare to two or present one as a replacement for the other.
If I thought an IDE was better for large Java projects than vim, then I'd use an IDE instead of vim for large Java projects. You'll find that many vim users do not use an IDE because they've found it to be more productive for them to use vim + command line instead. In those cases, there is clearly a choice being made about IDE versus vim. If you want to be pedantic about the fact that vim is just a text editor, then just imagine that whenever someone talks about using vim instead of an IDE or compares vim to an IDE, just replace "vim" in your head with "vim + command line". If you do this, you will better understand what they're saying and you won't have to get on the apples-and-oranges soapbox quite so much.
Great article on this very point: "Build an IDE with tmux and vim"--http://alexyoung.org/2011/12/19/build-an-ide-with-tmux-and-v.... The money quote: The difference between this approach and a traditional IDE is this interface adapts around my current task, and is only limited by the thousands of commands and scripting languages that I have installed.
Except then I still don't have any interface builders, out-of-the-box code completion and on the fly compiling/checking for small mistakes, easy navigation through class hierarchies ("click on Classname, function etc..) plus showing me documentation alongside, refactoring tasks, all sorts of useful and some useless wizards etc. and we haven't even talked about more specific things like developing for iOS.
So IDE is still ahead in terms of what it has to offer me that not even vi+console or vim+console can. My point stands.
If your point is that this handful of advantages is a slam dunk, and that it makes IDEs and vim+console incomparable such that whoever does so is making a categorical error, then your point has no legs to stand on.
You belittle clear advantages simply because they do not fit your taste or style while the usefulness and spreading use of IDEs is unquestionable, so this is too much of a personal preferences discussion than anything else, just like all vi vs emacs flames have always been and I find it disappointing that in 2012 this STILL keeps coming up... I thought I had FINALLY left those zealots behind me in the 90s. And I really do not like your tone.
I am more than sufficiently "fluent" in pretty much all common IDEs and in vi(m)+console so that I don't really care which one I am using or have to use neither do I care on which OS... most of the time I end up in a good IDE because for a lot of the tasks I want to do and get paid to do, there are no real alternatives in vim+console, they might be specific though.
The article argued vim's superiority in editing so comparing that to an IDE really are two completely different things. Comparing vim+console to an IDE is always going to be all about personal preferences and which extensions do you use in the one or the other, which tools/options/tasks are available and which aren't - but ultimately they cater to two usually very different crowds: the console-lovers and the oh-shiny-clicky crowd and you will find it very difficult to even remotely describe an advantage of the one to a member of the other crowd... and that's where the comparison doesn't add up and feels to me like apples-oranges.
Comparing vim+console to an IDE is always going to be all about personal preferences
That's been my point from the beginning. Tradeoffs between personal preferences is a hallmark of apples-apples comparisons. I mean apples-apples in the sense that both toolsets are used to accomplish the same exact things. I agree that there are the two general types of people that you describe, but I disagree that they are so irreconciliable that they shouldn't even attempt to discuss the tradeoffs. It is a perfectly reasonable discussion to have.
I mostly use Eclipse with the Emacs+ plugin for code development these days. Emacs+ provides an almost flawless Emacs experience, except for that fact that Eclipse is kind of a pain in the butt and often sluggish at manipulating text. It's sluggishness does interfere with my thought processes. Eclipse is very helpful for some things, but it would have been oh so much nicer if the features of Eclipse had been incorporated into something with the fluidity of Emacs. It's too bad that Lucid went out of business.
I use cscope as my backend for vim, there are other ways to get your IDE going. Adding a vim emulator would not be as good as just using vim, imho. http://sourceforge.net/projects/vimplugin/ is the vim plugin for Eclipse if you can't live without Eclipse. I can't live without vim, myself ;)
I've never really felt comfortable in vi. I first started using it in 1989 at home, used it throughout college, and then used it on-and-off during my career, but it's never really felt powerful compared to a GUI editor.
I want a scrollbar. I want a list of files in my project that I can just click on to open. I want tabs I can click. I want multiple windows that I can alt-tab to. And since I spend most of my time thinking and modifying code, I'm more often than not thinking in terms of tweaks and copy/pasting between files rather than "replace in this block of 3 words". A mouse and GUI just feels a lot more natural to me, even after 20 years of vi.
I'm with you. I want tabs, I want multiple windows, I want an easy list of project files, and I don't want to waste time thinking about editing. That's why I use vim.
If anyone is looking for tabs in vi, try out the (you'll never guess) tab feature in vi http://vimdoc.sourceforge.net/htmldoc/tabpage.html . What is great is that text completion (ctrl-p) works across tabs, so if you are using a library, open it up in a tab and you can ctrl-p away.
For extra points, learn to use hjkl and map your arrow keys to switch tabs.
Yes, this. About a year ago, I finally bothered to understand the buffer concept in vim (after a brief stint in emacs), and suddenly any tabbed editor felt clumsy.
I'm with you. I think an equivalent post could have been written on how programming in GUI is much better. What it comes down to is pretty boring and unsatisfying-- both have strengths and weaknesses, and these depend on the specific application.
if you're on linux, ctrl+shift+T usually brings up a new terminal window if you're running a desktop. you can alt+tab between these just like you can alt+tab between GUI editor windows.
Just the opposite. I find all that distracting. My hands never leave the keyboard. The mouse is a nuisance. I'm far more productive without all the GUI crap.
Whenever I am using a program other than vim I feel clumsy.
Plugins for Eclipse, Chrome and so on will only bring you so far. The other way around, namely turning vim into a multipurpose IDE does not satisfy my needs. One needs to admit that some features (refactoring support in Eclipse for example) cannot be matched by the available vim plugins. I know there are other solutions, like eclim, but I am looking for something more universal (think of using vim bindings in your email client).
This is why I have been thinking about implementing a vim emulation layer recently, so that every program can profit from vim keybindings. Basically this would be implemented as some form of keygrabber that would translate vim specific commands into regular ones.
Does anyone know of related pre-existing projects one could use as a reference. A quick google search did not deliver any results for me.
You didn't specify an operating system, but for OS X there's KeyRemap4MacBook[1]. Among a zillion other things, it has a setting for "Ubiquitous Vim Bindings" which enables vi-like bindings everywhere, except in terminals, emacs, and vi itself. And some things like password dialog boxes default to insert mode.
I'm not a vi person myself so I can't comment on how effective it is, but I do use KeyRemap4MacBook to enable certain system-wide emacs/readline-like keybindings that are missing (C-w for backward-kill-word, C-m for return) and some ergonomic tweaks (Return key mapped to Control when held down, because I don't have a right-hand Control key on my keyboard).
Is there a big reason an IDE couldn't have a child editor process running inside the UI, and operate directly on the file? That would allow you to plug the editor if your choice into the IDE.
I use vim for about a year or more, and I like it, however I'm still having trouble with copying and pasting tiny fragments of text. Maybe someone can help me out with this?
1) If I yank a line with yy, pressing P or p will insert the text into a new line.
2) If I go to visual mode and select a region, yank it with y, then press p/P, it gets it inserted into the current line.
That is, vim preserves new lines.
What I can't figure out is how to paste into the current line in the first case, and, vice-versa, how to easily paste into a new line in the second case (without doing :put, or opening a new line).
There's no good way to do it, unfortunatly. You need to yank the contents of the line without yanking the entire line qua line. Now, if 'l' were a text object for 'line' then there would be an obvious 'yil' for just getting the inner stuff, but since there isn't you'll have to do
0y$
to go to the start of the line and yank until the end of the line. That'll store the line contents instead of the line itself, so p will do what you want it to.
That is, i<C-r>0 will paste a line character-wise, but the EOL will still be there, so you might have to join lines afterward. Alternatively, you could not yank the EOL with ^y$.
For making a newline with a character-wise yank, use o or O to make the new line and you can use <C-r>0. Or Escape and p.
Whether it pastes a newline or not depends on whether you yanked one. I guess this is what you mean by "vim preserves new lines". Don't all editors work this way?
If you want to yank a line character-wise, you would do something like ^y$. I have Y mapped to y$ for this sort of thing.
You cannot yank a substring of a line line-wise. That doesn't really make sense. I typically open a new line with o and then paste in insert mode with <C-r>". So o<C-r>".
Seems like my description was incorrect. I meant that there are two ways to deal with text: line-wise and fragment-wise.
In most other text editors, if you copy a line, and then paste it, it gets pasted into the cursor position regardless whether you copied a line or a fragment (fragment-wise). In Vim, lines yanked with 'yy' disregard the cursor column and get pasted into a line above or below, while fragments yanked with 'y' (e.g. '0y$'), take into account the column.
I like how in Vim you can do line-wise editing, but I just miss an easy way to paste text to the position starting with the current column regardless of the way I yanked it.
you can always map <leader>y to yank line except for end.
Mapping the leader to , and it's even nicer. then all you need to do is ,y and you get the line in fragment mode.
nnoremap <leader>y 0y$
or if you want just first non whitespace char you could do an uppercase y for the leader command. swap the upper and lower to make it how you want. seems like this would be a more useful command to have:
nnoremap <leader>Y ^y$
edit: saw that you found a workaround by pasting in insert mode. ctrl-r" any other ways to paste in insert mode?
Put this into your vimrc to make lines behave like they're a text-object. Then to yank a line without the carraige-return, it's just yil or yal (yank in/a line)
vnoremap <silent> al :<c-u>norm!0v$h<cr>
vnoremap <silent> il :<c-u>norm!^vg_<cr>
onoremap <silent> al :norm val<cr>
onoremap <silent> il :norm vil<cr>
For the first, you need to do a 0yt$ .. this will yank to endline, but not include it. The whole line can then be pasted into another without breaking it.
The 2nd can be o/O<esc>p .. Maybe there's a more elegant way though!
You could bind these to, say, <leader>p and <leader>P, if you find yourself doing it a lot.
For #1, the yy command will yank the entire line (including the newline). Try using y$, which will yank from the cursor to the end of the line (not including the newline).
To the certain extent, yes, it makes sense. This trouble is rather small compared to benefits. I'm in constant search for the perfect editor, but every editor has its quirks, and of course, most editors require learning.
As for the controls that contradict with the rest of the software, there's no trouble for me at all. I don't suddenly start pressing :wq in the browser. As a simple example, consider people like me, who use two keyboard layouts: one for their native language and the other one for English. Even punctuation marks are on the different keys, but I don't have trouble typing the correct ones depending on the current layout.
'basic functions' in this case being the subtle difference in two kinds of pasting that he already knows how to achieve, and is asking for another way to do one of the paste formats.
Yes, joining works when I want it to appear at the end of the current line, but I want to it to appear at the cursor. Anyway, seems like pasting in the insert mode works the way I want, for the first case.
I know this will be an unpopular comment, but my whole problem with it is actually the attitude of those that use it. After reading the article, I was really impressed and imagining all the ways it could help me after what, 8 years of coding into an IDE; and then I got to this:
"Do whatever you want. Don't learn it if you feel it's too much effort just for nothing. Learn emacs instead. Or stay in your IDE using a lousy editor. Whatever. But in any case, don't ever claim again that those 'vi guys are nutheads' - I hope that I have succeeded in showing you why they (we) stick to it, and you should at least be able to understand its power, even if you prefer to stay away from it."
I'm the author of the article. Yes, the ending is anticlimatic, but the only reason is that I didn't want to "push" it on people. I just wanted to share my views. I thought many people would complain of fanboyism if I finished with a push to use it.
I used vim for about 9 or 10 years before I switched to emacs. From my perspective people use vim because they haven't tried emacs yet (I kid!).
I still have the muscle memory for vi and that's what these sorts of editors rely on to be effective with them. Once you get enough practice the editor practically disappears and it becomes more about the text on the screen... almost like you are manipulating it directly with your mind.
Augh the muscle memory! I used vim for five years in and out of college and then switched to emacs for the cool things you can do with SQLi-mode and shell-mode. Once in a great while I have to edit something on a machine I can't TRAMP to and I use vim, and then my fingers are completely shot for about an hour because they keep trying to type esc :wq instead of C-x C-s.
I'd be interested to know how much of the stuff presented in the article is actually present in plain vi (not vim). If you mean vim, then say vim, not vi. They are two different things.
No. It was like that (where vi is just a lightweight recompile of vim) several years ago. Since then Arch has switched to using ex-vi[1], the closest thing to 'authentic' vi you can get nowadays.
Sounds reasonable. I was about to guess a similar thing. A minimal Debian install (perhaps Ubuntu and other child-distros as well?) installs a vim-tiny[1], which often throws people off[2].
The last time I used AIX (I believe it was 5.3), it had old-school vi on it. I would bet this is true of newer revisions of AIX, as well as other commercial UNIX(tm) systems. I would also not be surprised to learn that some/most of the BSD systems still use it.
I don't think any of the free BSDs distribute the classic vi by default anymore, but they've standardized on nvi rather than vim as their "enhanced vi" of choice.
What I want to know: how good is the best autocompletion available? Does it stack up to Visual Studio's Intellisense? (For statically typed languages, that is; Intellisense doesn't work very well for eg Javascript).
For all your programming needs I would highly recommend JetBrains products.
I am currently evaluating PyCharm and their JavaScript and Python editors are awesome. I was mostly using vim and tmux for Django development until now. Using vim plugin in PyCharm feels really 21st century.
It kinda feels like VisualStudio + ReSharper (also a JetBrains product) for .NET
To be completely honest if you were impressed you shouldn't have been. Learn your IDE!
Apart from the douchey tone of the article, the thing he misses is that most editors can do this stuff, you've just got to make a bit of an effort to find out how.
Emacs/Vim force you to learn this stuff as they suck without it. That's one of the big difference between Vim/Emacs and others, people don't realise they can do so much more with IDEs.
For example in VS2010 with the MS productivity tools extension:
Example 1: Use ctrl-shift-r/ctrl-shift-p (temp macro), actually less typing than his example due to auto-bracketing. Also learn how to use snippets.
Example 2: I'm dubious on the value as believe this would require cognitive effort that I'm using for the code. I suspect hunt-and-peck (and only 4 or 5 keystrokes using ctrl-arrow at that) is probably better than switching mind modes to figure out the best cmd. For example won't handling entry.key().equals(qk.key) instead require different keystrokes, hence thought?
Example 3: Use End, Shift-Home or Home, Shift-End instead
Example 4: Use home, end, ctrl-pageUp, ctrl-pageDn to mostly deal with this
Example 5: VS does this automatically on paste, so no typing at all required. If it really struggles you can use shift-},tab to indent an entire block, assuming starting on the { as the article does.
Example 6: VS highlights end tags automatically without you even having to press anything, there's probably a command to select the enclosing block but I've never looked as it happens so quickly I don't think it's worth the time, here I just End, shift-upArrow a few times or go to the mouse. Deleting a whole block of code generally requires some thought about what it was doing, you're not in edit mode at the point of deletion. If you're looking for multiples then ctrl-F (find) will highlight all instances of the word your cursor is on, this is easier with productivity tools installed as it doesn't open a dialog. And VS also has the excellent rename all instances of this variable only in the right scope.
He keeps banging on about fingers staying on the home row, but I don't really notice moving to the arrow keys, perhaps it's cognitively similar to switching to/from insert mode.
I had to actually do all of them a few times to be able to write them down as just like Vim/Emacs, that's all muscle memory to me now.
NB for example 5/6 I highly recommend changing the default colour of highlighted start/close tags in C#, the gray MS uses is far too light given how important it is. This is pretty much the only colour I have ever bothered changing from default.
The other massive productivity thing in all editors if you didn't know it is ctrl-arrow, moves along words instead of single instances. Holding shift works as expected and you can hold shift-ctrl with one little finger. But I'm sure everyone knows that one.
In regard to the productivity tools, I would turn off the auto-correct mixed tabs as it moans all the time when you look at downloaded code and also 'Quick Access' too as that's annoying.
All that power without months of learning a new way of using a text editor.
Example 1: use q to make a macro and then invoke it with @ and it would be even less typing. There are many, many ways to edit in vim.
Example 2: If you press dW it deletes the whole word. which would be the entire entry.key().equals(qk.key) string. dw would delete up to the period. d2f) would delete up to and including the second right paren from where you are. I personally use delete whole word a lot.
Example 3: the di> would delete everything inside the brackets even if they spanned multiple lines. you also can be anywhere inside the bracket and this will still work. This also works with other types of tags. di) would do the same for the current level of nested parens.
Example 4: really only offering one way to do granular navigation vs. many different ways that might work for a particular situation. learning them is not that hard when you take into consideration the mnemonics involved. you need to learn some verbs to be effective: d is delete, v is visual, c is change, w is word, f is find, t is find unTil, p is put, y is yank, a is after, b is back, etc....
Example 5: There are plugins that can do this automatically in vim too. The larger, more interesting thing is the ability to do entire operations on text blocks and I think that is more important than the particular case of automatic indenting.
Example 6: you can also get a plugin that does the highlighting automatically.
The fingers on the home row is pretty awesome. there is a cognitive load to navigation to precisely put your hands on the arrow keys correctly. To get back to normal mode you can either slap the escape key(not as good) or remap escape to jj(or some other not commonly used key sequence) while in insert mode.
The macro system in vim is excellent. everything is text so you can look at the macro commands and edit them if you made a mistake. There are a lot of registers(basically named clipboards that you can use to copy and paste text the " is the default clipboard when you don't actually specify a yank target.)
Your point was that the ide is great and can do all that vim can do, but you only showed that aside from some special case things with snippets and auto indenting. After you have gone past the special case stuff that your ide can do you have to resort to hunting with the arrow keys.
You can be productive in macvim quite quickly as it affords all the fun copy and paste stuff like you are expecting to have at the os level but still have all the vim goodness underneath. at the end of the day go for whatever you feel most productive in but there really is a reason that after you get competent with vim/emacs you are extremely productive.
You kinda missed the point of my comment, it's just demonstrating that there's nothing amazing about any of his examples.
I'm not denying some things are faster in vim, but other things are slower.
What I take umbrage with is when someone posts a load of examples like this where they can all be done in your favourite IDE but the author's just too lazy to find out if they could be and so declares the magic of Vi or Emacs compared to [insert everything else here].
Often it's like saying 'look my car's got windscreen wipers, all your cars suck'. Um, mine has windscreen wipers too dude.
See my response to vacri, if you've any examples, please do share. I honestly will switch if I could see a sizeable productivity gain.
To be fair to the author, the post is to convince people to use viemu, his product which gives vi controls to Visual Studio. So, I think he probably agrees with you with regard to IDEs.
I agree that there was nothing amazing with the examples that he gave. you can do anything in notepad that you can do in vim as it is all text. I actually like using my editor because it conforms to how I want to use it. it is very fast at slinging text around. Vim is a text programming language and you are learning the syntax of how to program in it. I like the satisfaction of being able to cut and paste text without thinking about it much. navigation is smoother as it's less disjointed to navigate by block than it is to navigate by pageup, pagedown; everything feels smoother.
It takes a bit to get used to the language of vim but once you do you will see. I also don't get why you need it to be mutually exclusive. If I was doing a lot of windows coding I would probably use visual studio with the vi plugin.
Stuff like vim surround is a great plugin if you regularly need to write html or strings that you forgot to surround with quotes.
example of that:
Usage:
Old text | Command | Result
|IShot The Sheriff | yssA | <a href=""> I Shot The Sheriff </a>
One of the best things about vim is the capability to map keys to other keys and have them either recursively act or non recursively act. EVERYTHING* can be customized. There is also something awesome about having most of the commands be one key as it really speeds things up. for example just moving one word right would be two uncomfortable keystrokes in vs(ctrl-right arrow) vs just one(w).
To be fair I think the author is not dismissing all other cars as not having windshield wipers; I think the author is more saying that my car has windshield wipers that you can turn easily and other cars have it so you have to turn them on via the glove compartment. ;)
Everything feels fast when I am using vim well and I just can't say that about any of the IDE's(I have used visual studio professionally for years and was constantly looking for performance shortcuts).
How does VS2010 compare to vi when making a change to a config file on a remote machine?
He keeps banging on about fingers staying on the home row, but I don't really notice moving to the arrow keys, perhaps it's cognitively similar to switching to/from insert mode.
It's slower. I still move to the arrow keys in vi for some reason, and it noticeable slows me down when I do so. The physical movement of your arm there and back takes time, plus you can't run any other "right-hand commands" while your right hand is out of place. In terms of workflow there's no difference, but in terms of speed there definitely is.
I've not seen an emacs master at work, but I've seen a vi master at work and they are simply stunningly fast at manipulating the text. I've never seen a gui editor master come anywhere close.
I'd honestly love to see some videos. I want to see how it is faster, what it could give me. If it is I'm all for jumping ship, I've honestly never seen a Vim/Emacs master at work. I have tried to find video examples before because I want to see if it is worth learning.
I am only pointing out that all the author's examples are achievable in most IDEs, you just have to learn. There's nothing special or magical there.
And IDEs have other advantages. The phenomenal amount of code completion VS does for me means I generally only ever have to write a variable, function or method name once and from then on the first 2 characters will pretty much finish it off for me as VS is totally context aware. Not in a file, but in an entire project, in an entire solution made up of many projects. For all the imported libraries. Contrast that to basic auto-completion which can only take you so far.
Snippets make anything boilerplate fairly trivial. Using statements are included at a ctrl-. enter as VS recognises the desired namespace. You can write function calls without them existing, ctrl-. enter, and VS will add them for you in the right file which you can then jump to after you've finished the line by pressing F12 and immediately start on the new function or object method, which already has the correct parameters.
Maybe Vim/Emacs can do all this too, but it's just demonstrating that you can pump out 100s of lines of code in very little time if you really want to. But it's rare for anyone to keep that up because that's not real coding. Maybe if you'd written the program before. Real coding is thinking or physically writing in a notepad for a while, then writing at most probably 20 lines and then pondering and then writing a few more lines, pondering some more, then maybe another big burst, then some more tweaking.
At least that's how it is for me.
For example the answer for VS to this video question of 'can your editor do this' http://www.youtube.com/watch?v=pCiVCiku3cM is yes. It can. But how often do you actually do crap like that?
But there's no good videos I can find demonstrating the famed Vim or Emacs power that gushing articles like this profess which I've been able to find. And almost every single time with the examples these articles provide I find myself thinking 'but I can do that in the same number of key presses in VS'. Often even less key presses.
I don't have videos to hand, but the vi master I know is a sysadmin rather than a coder - lots of glue code and config changes. I can't say I've watched a full-time programmer code in vi.
When I first starting playing with linux, I watched him get into a remote machine, replicate a few blocks in a conf file and customise them in vi, then restart the service, all in the time it would have taken me to simply complete my Windows remote desktop request.
I used to hook up auto completion to my tab key in vim, worked fine in c/c++ at the time. It would pop up a window of the options, but I stopped using that feature at some point.
Reading the article and the comments here, I came to the conclusion that I seemingly don't really use vi. As in: I don't live in it.
On a typical day, I work with my files using grep, awk, bash, python, sed, make, cat, xargs, etc. And, of course, vi.
But I don't really use it like some (most?) people here seem to do. I don't list and navigate through files in vi (I use tree, ls and find for that). When I use vi, it's mostly for short bursts of manual editing. Occasionally, vim's syntax highlighting comes in handy - but that's about it.
Don't get me wrong: that is exactly why I _love_ vi. It starts fast[0]. It fits in pretty well with the rest of the unix environment (it can read stdin, for example; and with vim you can open multiple files given on the command line - and you can construct that file list with any of the standard unix tools, of course).
So, for me, the question "IDE or vi" ends much earlier. I don't even come to the point where I could discuss editing features. Can't read from stdin? Doesn't start in less than 1 second? Doesn't fit into my work-flow.
Of course, vi(m) is a great editor, for all the reasons mentioned here and in the article. But the unix user-land has some great tools, too. And it includes vi. So it is by definition an even better editor than vi. :-)
So that's what I use.
[0] Believe it or not, emacs starts still too slow for me. These one or two seconds tend to disrupt me a lot (I've tried it, with GNU emacs). And, as I said before, I invoke my editor pretty often, maybe 50 times a day.
If you use vim then I highly recommend mapping spacebar to page-down and shift-spacebar to page-up. This key is kinda useless otherwise and super-helpful afterwards. It is also the largest key on your keyboard. usability++
I'm realizing that the distinction between vim/emacs and typical IDE editors is entropy. Vim is extraordinarily precise - very low entropy at all times. An IDE editor is constantly moving between high entropy (e.g. mouse motion) and low entropy (e.g. the interpretation of the mouse motion as a precise command). This implies that vim appeals to minds that desire constant precision, and GUI editors appeal to minds that prefer to vacillate between levels of precision.
Decoupled from this is the question of which pattern of thought lends itself to being a better programmer. There is a good argument either way: staying at a very precise level of thought is wonderful when solving problems; and yet it is better to loosen up when figuring out which problems to solve.
I tend to take the view that a programmer's actions while programming should ideally be unambiguous, precise, and regular at all times. Higher level thought should have a distinct place, time and another set of tools (pencil and paper being foremost among the alternatives).
That is my belief, although it is based on anecdotal evidence. Some (most?) hackers enjoy descending into and inhabiting continuously a low-entropy mind-state. There are others that would rather maintain some sort of fluidity between states, as inhabiting that low-entropy mind-state tends to come at the cost of human connectivity.
One of the great things about vim is that even if you use it as your regular editor (I use MacVim), you tend to learn something new every time you read a new article. Today I learned about the '.' command.
= will also indent any selection you have automagically. gg=G will do your whole document, and V[selection]= will give you a selection range to indent. < and > are nice as well for indenting specific amounts in the left or right direction.
I really don't get how its more efficient than a modern editor!
I use vi(m?) when I am working on a unix/linux/mac terminal and have done so for 10+ years. But I never bothered learning it properly so I only know a handful or two of commands. So I can't appreciate both perspectives clearly.
However, how can it be faster and more efficient to edit in vi than in a modern editor? I'd assume that if you can use multi gesture scrolling, point and click location, the modern editor type keyboard shortcuts (with multiple keys pressed) that it would lend itself to be faster to work with and more "efficient" somehow (hard to explain).
Would love to know what vi-people think about that because I am most likely wrong (as I said, very one-sided experience) but would love to get that level of detail (I don't think the story was iron clad on that point).
Is there anyone who has switched from many years of very happy vi onto modern editors and love that more?
I feel like such a tool for saying this, because I thought people who said this were tools before I 'got it'. Taking your fingers off the keyboard and to the mouse and trackpad is slow. I now even get how moving your fingers to the arrow keys is slow. I never thought I would believe it, but somehow here I am, spouting the same nonsense.
It's true. I think there is just some mind-body-editor connection that develops with vi(m) usage (and emacs, I don't know). When you really start thinking in vim, your mind starts describing what you need to do in vim commands, that magically flow out of your fingers, and vim responds.
In other editors, for any task I need to do, instead of telling my editor to do something, I have to show my editor how to do it by selecting text and menu items with the mouse, it just feels clumsy.
Once the keystrokes are muscle memory, it's impossible to beat with point and click in terms of speed.
That's just an opinion from a vim novice that can never go back.
I've used Vi(m) enough to know that I'm far more efficient in an editor designed to work with my OS.
Knowing Vi (or Emacs) is essential as a software developer, but using it as your local code editor has never made sense to me.
What most people who pontificated about Vi/Emacs/editor-of-choice often fail to realize is that there isn't a "One True Way To Do Things Bestest". Everyone works differently. Using Vi for 30+ hours isn't going to make me a better developer - and it certainly isn't going to speed up anything.
To start with, the way vim keystrokes combine is pretty nifty. To move forward a word, w. To delete the next word, dw. To delete the next 6 words, 6dw. To move to the next "g" character on the line, fg. To delete everything to that character, dfg. To delete everything inside the parens surrounding the cursor, di(. Something I do a lot with viemu in ms sql: Select everything inside parens with vi(, then hit F5 to execute the subquery.
But it got really fun when I started using macros. Once you're doing everything with keystrokes and text objects, you can record a macro while you're doing it. So, keeping with sql, let's say I want an update statement.
First I use an IDE feature to give me a list of all columns in a table, comma-delimited.
qa starts recording a macro into register a
Wi<return> advances to the next column name and inserts a carriage return
<Esc> q stops recording macro
10@a plays the macro ten times
Now I've got each column on a different line. I go back to the first line.
qw starts recording a macro into register w
ia.<Esc> puts "a." at the beginning of the line
yw copies the column name
A = b.<Esc> goes to end of line and adds " = b."
pA, pastes the column name and adds a comma to the end
j^q moves to beginning of next line and stops macro recording
10@w does the same macro ten more times
Now with a few keystrokes, I've changed this:
column1, column2, column3, ...
To this:
a.column1 = b.column1,
a.column2 = b.column2,
a.column3 = b.column3, ...
And the key point is, I did it without having to think about it much. I used the same editing techniques I would have used to make that change for just one line, and with half a dozen extra keystrokes I made it apply to as many lines as I needed.
Possibly I made small mistakes in the exact keystrokes above. When doing it for real, you see all the changes on that first line as you do them, so if something isn't quite right, just hit u to undo and keep going. It's so easy, I can record and replay new macros all the time. I almost never have to do repetitive editing.
Another trick, not available in viemu but available in vim: select a bunch of lines, then type :norm and your next editing commands after that will get applied to all the lines. For example, to add a comma to the end of every selected line, :norm A,
In fact learning vi/m is a lot like learning to play a music instrument.
It is a pain to start using vim. But if you reach a certain level you start improving more and more. Concerning vim, it should takes some weeks to be as efficient than with notepad.
Honestly, when I was younger, I used to use vim when collaborating with other programmers to impress them, and then use an IDE most of the time when noone was looking. But then something strange happened, I began building up the muscle memory and eventually preferred using vim over an IDE. It seems like every year, if I take the time to learn more about vim, I become twice as effective as the year before. There seem to be an infinite amount of new things to learn, constantly making my life easier. I've been with it 4 years now, and will never go back to an IDE.
The coolest thing I learned this year is the '. command, which will go to your last change. So, you can be editing a program/script, run it, and it has an error. Most of the time you want to go back to the last modification, so just type:
'.
This even works, at least on my system, after closing and re-opening the file. Related to that, you can type g; and g, to go through next/previous modifications.
I read your article a few days ago, great stuff. I agree vim is a pain in the beginning, and I only recently went to using it full time. But even after two weeks of full time use a lot of the commands are already starting to get "embedded" in my fingers.
I'm extremely passionate about vim, and I cannot type with a plain QWERTY keyboard. It's really not a big deal. I remap h,j,k,l to d,h,t,n (and n to l so I can search) and I'm off to go.
The one problem I have is that my vimrc/.vim stuff is all customized far enough that I can never use any of the vim-like emulated modes in other text editors. I think evil-mode may be possible if I wanted to learn how to configure emacs at all, but it's generally not worth the hassle. I'm not sure about the particular Visual Studio plugin that the link is to, but one of the two doesn't allow remaps, for instance. It's generally not a problem to use j/k for short periods of time at least. My big problem Dvorak wise is Nethack which is sort of a pain. I bought a Qido USB layout switcher to make games like that possible.
Pleasure to meet you. Not sure how much passion you require. I'm not exactly head-over-heels with vim, but I have been using it for about 7 years and dvorak for about 3.
Yeah. Adjusting to typing in Dvorak took me considerably more time and effort that getting used to the new shortcuts.
Luckily, Dvorak isn't that bad for this. For instance, 'j' (down arrow) and 'k' (up arrow) are still next to each other, in the same order.
'h' (left arrow) and 'l' (right arrow) are not, but when you have your right hand in the starting position, their location and distance is very similar to where they are on QWERTY.
As a side note, it's much harder to type QWERTY on Dvorak.
Now, the arrow keys no longer in the same place -- up/down is on the left side of the keyboard whilst left/right is on the right side.
But that's not as big a problem as you may think -- provided you keep both your hands on the keyboard. Interestingly, the Kinesis Contoured keyboards [1] have the arrows similarly separated.
And there are no "gotchas" where the keys' position would go against the spatial intent.
You could imagine a layout that would for instance have ctrl-f (page down) located below ctrl-b (page up) or 'h' (left arrow) on the right side of 'l' (left arrow). But that's not the case in Dvorak neither for vim nor for the emacs keybindings that I'm familiar with (c-b, c-f, c-a, c-e). Sheer dumb luck, methinks.
Both under vim and under Gnome in general, I've found that all the shortcuts I'm using aren't that much worse off. Some are actually better. It seems to pretty much balance out.
Heh, not at all related, but do you really find it harder to type qwerty? I personally find that typing a bunch of letters that are all beside each other is actually harder than typing normal words.
I remapped hjkl to htns (the keys directly under the right fingers on the home row) and it works wonderfully. 'n' then needs to be remapped, so I have 'N' set to 'j' and 'n' set to 'k' so that the two commands for repeating a search forward or backward are adjacent keys on the Dvorak keyboard.
No other changes required. I don't use vim's 't' or 's' commands, so no problem there.
If you're a little pragmatic about it like me, you can still use the arrow keys to move around, at least in vim this works out of the box.
I've been using VIM for over a decade now, and learned to make good use of many of its features, but I've never had the urge to stop using the arrow keys. Except when working remotely to some ancient Sun or HP box that only has vi, or some crappy terminal settings that mess up the arrow keys.
The idea behind hjkl is that it's supposed to be faster because you don't have to move your hands away from the letter keys, but in practice, I don't actually move around in single-character increments that much when editing anyway.
Just wondering how much dvorak gets in the way of vi/vim. Lots of wonderful answers showed up in this thread! Looks like dvorak is a small obstacle (because of hjkl) but not a show-stopper.
That's been my experience at least. But remember that this is very subjective and different people will have different habits.
It's quite possible that there are shortcuts that get crippled by the Dvorak layout -- I'm just not aware of them.
Also, muscle memory is a strong thing. Expect at least the first few days to be slow and painful. And as such, it's quite possible that all my positive experience now is due to cognitive dissonance.
I'm one of the really blasphemous vi nuts who uses both Dvorak and the arrow keys for movement. I keep a very minimal vimrc, and I don't use or remap the standard hjkl keys. But that means I can also seamlessy switch between multiple IDE's with vi-compatible modes, and have zero problems using vi/vim on machines that don't yet have my vimrc set up. I feel that it gives me a superior editor with a superior keyboard layout, and the flexibility to use some of the best tools for the job.
For the record, I use a "Tenkeyless" [1] quality keyboard, and depending on what languages I'm working on, I use:
- vi/vim for editing one-off files or small, isolated projects
- Sublime Text 2 with vintage mode for Python or PHP projects
- Eclipse with Vrapper for Java/Android projects
- Visual Studio with the OP's ViEmu plugin for C#/Xna projects
Not sure about passionate, but I like it enough that I use VsVim for my day job (.net developer).
I actually started using Dvorak before picking up vi; never had a problem with the keyboard mappings. It helps that j and k are still next to each other, and h is to the left of l.
I use vim a lot, but I only really started using it for most of my work in a job I had after switching to Dvorak -- was primarily an Emacs user before that.
I've been learning Colemak off and on and am a bit worried about using it with Vim.
What mappings do you use (particularly for hjkl)? My first instinct was to map them to something more comfortable, but lots of other apps use those keybindings so I feel like it might be better to just learn to use them as-is.
Interesting article, I have always been interesting in moving to Vim, and this article all but sealed the deal for me. The only problem being I don't really see how useful this would be for general notepad usage. I understand the author of this article is selling his plugin for Visual Studio, and this is a marvellous way to do it. Is there any other way to integrate vim with Visual Studio 2008 without purchasing his ViEmu? I would love to start learning vim but I doubt a trial would be enough, and I don't see most of the other attributes he covered ('.' for example) being very useful in daily notetaking.
First, you understand how and why it is modal. Then you learn simple commands for movement and editing.
Then you learn all the meta-commands. All of these building blocks are only limited by your creativity of combining them to get what you want done. The more commands and tricks you know, the more you can slice and dice text, code, logs, whatever inside your editor (without leaving it).
I guess it's just a Unix/neckbeard thing. This is how the rest of Unix is designed, so why not the editor.
A couple of years ago I was recommended to read this article as I was doubting if vim was anything for me.
It convinced me to give it a try and after two weeks of learning it felt I could never go back. Since then I have vimified everything I can.
Later I have recommended this article to others of whom some have had similar experiences...
The author does a fine job describing the vim-philosophy instead of just a bag of tricks.
It's fascinating how excited people get when given the chance to talk about their favourite editor!
Further down in the comments it always gets to the point where someone asks: "Yeah, I'm trying to learn vi, but how do you delete 3 lines?", or something like that.
I used to be in the "eww, vi" camp before taking a sysadmin job that basically forced me to use it. I used to remove vi at my first opportunity and link /bin/vi to nano instead.
Well, almost a year later, and I can't use nano without being irritated. All of the jumping around the keyboard for functions seems really inefficient all of a sudden.
Vim - :wq! :D
Nano - C-o <ret> <ret> C-x >:(
Probably the reason that emacs feels so wrong right now, though I'm doing my damnedest to become at least basically proficient with it, if nothing else for all of the ancillary features (like a really nice IRC client or the best text-mode organizer I've ever seen).
I guess a nitpick on the article. When you say a "Steep learning curve" doesn't that mean the time to learn is quick? (Think X/Y plot with Time being independant, steeper slope indicates faster learning?)
He is using "steep learning curve" correctly, in your example X-axis is what you want to achieve and Y-axis is how much you need to know to achieve it. The beginning part is a sharply increasing line for vim, you have to learn more to achieve the same amount on the low end.
I started attempting to properly learn vim a couple of weekends back, watched a load of vimcasts (http://vimcasts.org) and got my vimrc file all set up, but rushing to get things done before a release meant I switched back to sublime within a couple hours. Perhaps not the best timing!
Can anyone recommend a good plugin for switching between files frequently - as in the Command-T shortcut in textmate/sublime. I did try the CommandT vim plugin, but didn't find it as good as the implementation in sublime.
In his first example, implementing a header file/interface is only CMD-I in IntellJ. Everything else is done automatically.
I can understand why text editing is a big deal, but having an editor that actually understands your code is a powerful thing. Think of an IDE as a gigantic set of macros.
I believe I had two ah-hah moments about vim when reading this article. I love those moments! How I never knew about ]p is beyond me! I guess I should assume that something I'm doing that is annoying means I'm doing it the wrong way.
At this point, particularly on news.ycombinator, surely the article should be about "Why, oh WHY, do those #? nutheads not use vi?". It seems a majority of people believe it is better, certainly a majority of the vocal crowd.
I'd love to use ViEmu or VsVim, but it'd confuse the hell out of my team members if we ever have to pair up. And then I'd be lumped with trying to explain what it is to them when they barely even know what Unix is...
> The first time you stumble into vi or vim, you are shocked and disgusted that you have to use 'i' to start typing text. Can't remember which of hjkl moves in which direction. And you need to press 'a' if you want to insert after the last character of the line. Since you're already probably used to other editors, and if the arrow keys work in insert mode (they do if the system is configured properly, which is over 90% of the cases), you will stay in insert mode and not go back to normal mode except if absolutely necessary. You'll probably spend 20 minutes with it, and never go back.
All of this, except the 20 minutes part. I'd hate to have to spend that much time with one of these "enlightened" editors. Just let me use my arrow keys, please and thank you.
> Did you have this same resistance to learned when you learning the languages you are presumably programming in?
Speaking for myself, no. My reasons for disliking "enlightened" editors are similar to my reasons for disliking alternative keyboard layouts. If I can only be fluent in a highly specialized environment, in a sense, my skills become less portable. I like being able to walk up to someone's computer and just use it or help them with their issue. I do care about editing efficiency and superfluous keystrokes. But when I compared the keystrokes required to complete the example to what I would use in my preferred editor, (Programmer's Notepad) I didn't find the savings to be significant enough to warrant all the pain of learning a completely separate UI.
And FWIW, if I was actually doing that example in real life, I'd be in my IDE, clicking "Implement Interface", not wrangling text.
As for learning new languages, I enjoy doing it, and look forward to learning new ways of approaching problems that new languages can provide.
> If I can only be fluent in a highly specialized
> environment, in a sense, my skills become less
> portable. I like being able to walk up to someone's
> computer and just use it or help them with their issue
This is a non-issue. There are no versions of Windows, Linux or OSX that allow all text boxes to use Vi keybindings. The idea that if you started using Vi or Emacs bindings in an 'enlightened' editor, that you would lose the ability to edit textboxes on other computers is a straw man.
You could similarly say that you don't want to use VisualStudio because it would affect your ability to help out Eclipse users or vice versa.
I've certainly gone out of training on qwerty (or rather qwertz), but I was never actively impaired. Though in the last few months I went down the even more extreme route of getting a special keyboard not only an alternative layout. The Kinesis Advantage.
By the way, learning vi is probably the most standard compatible thing to do. Vi is a standard Unix tool, has been around for decades and will be around for decades more. (Not that I use vi much myself.)
> By the way, learning vi is probably the most standard compatible thing to do. Vi is a standard Unix tool, has been around for decades and will be around for decades more.
This feels a little bit like the scene in Superbad, where McLovin proposes to be named Muhammed to blend in, since it's the most common name in the world. It may be the most common OS in the world, but it's none too common 'round these parts. Off the top of my head, I can't even name two computers that have vi installed. The first is my work computer on which I installed gvim for another attempt after reading this very article.
I like being able to walk up to someone's computer and just use it or help them with their issue.
vi exists on pretty much every *nix machine out there. The only way this makes sense is if you mean "Windows computer", and even then extremely few of them have a text editor more complex than Wordpad, which has so few commands that yes, anyone can use them if they know ctrl+c/v and a couple of other things.
I do mean Windows computer. For my use, most of the computers I'd be walking up to do tend to have something more complex than Wordpad, like Visual studio.
Not that I'm a big fan of the douchey tone of the article writer, and apparently unlike this dude I find it trivial to switch between vim and Sublime Text or whatever other editor without having a crying jag, but...wait for it...vim does let you use the arrow keys.
He seems to be conflating vi and vim (personally I've only used vi once or twice in the last five years). Also, his grand sweeping pronouncement that you spend all your time in normal mode is, to me, utterly bizarre. I go into normal mode to do text manipulation. I live in insert mode because I'm actually writing stuff. In that respect it feels like every other editor ever.
If you're actually writing code from scratch in a linear fashion, then you do spend a fair bit of your time in insert mode. After a few years of vim use (about four years, so I'm not a grizzled veteran by any means), I've found that when I'm writing new code, I do use insert mode more often than usual.
But the difference is that when I need to make some edits to the code I'm writing, I immediately swap back to normal mode. It's not something you notice much if you don't use vi(m) a lot, but you go back and edit the code you're writing quite a bit.
From my experience with vim, this guy is spot on: someone who has really used vim for a long time will spend a majority of their time in normal mode, because literally you don't do anything in insert mode except write text in a linear fashion. If you want to move your cursor somewhere else, you go into normal mode to move it. If you want to erase a string you just typed, you go into normal mode. If you want to refactor your if statement into something cleaner, you go to normal mode. And the list goes on; normal mode, once you've learned it, is just so much more fluid that you will want to be in normal mode 99% of the time.
Vim can be a little crazy to use, yeah. But once you have learned it, it's unconscious. It reminds me a bit of algebra. When you first learn algebra, you're really focused on the symbolic manipulation. But as you get into the higher maths and have more experience, you'll find yourself rearranging equations without any thought. Vim is the same way, and that is what makes us vim users addicted to it: complicated text editing becomes subliminal.
Vi/m is a funny hat that I put on and that gives me powers. Let's call it meta-learning! I'm writing code; now, I'm writing code with a funny hat on. _This_ computer's funny hat!
The great thing about Vi/m is that it compels you to read by withholding input entry. Key-bindings are secondary, but no less significant in that you can use two different object languages for dealing with text. Being forced to read through navigation of text with a robust language aids in presenting analogies to the coder. Who is entering the text? Does VISUAL feel like a finger pointing at the screen?
Vim is great but learning requires a good investment of time. If somebody tells you, you can be as productive as with your current editor in a few weeks, don't believe it. If all you need is notepad or gEdit, Vim is not worth the debt. Spend your time learning another language or create an open source project.
I live in a terminal so Vim is my weapon of choice. I tried and bought a license for Sublime 2, which is awesome n vintage mode, but Sublime is not Vim.
Learning vi is your standard process of enlightenment and elation followed by a lifetime of disappointment. Think about how you'd feel if you ate the best meal of your life at age 13, and the restaurant where you ate it went out of business the next day.
You'll be frustrated by all other software. You'll wander around trying to explain to other people why the thing you had was so good, and it was so easy, and that nothing else compares, and wouldn't it be great if everyone did things this way.
Exactly like the author of this article.
You have been warned.