Why, oh why, do those nutheads use vi?
viemu.com
viemu.com
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.
;-)
See my post below[0]. Your input would be appreciated.
Though vim is no longer my main editor I still use it every day. Right tool for the job and all that.
---
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.
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.
You have been warned.
;)
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.
Vi/Vim is off in its own weird universe.
see:
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:
inoremap <c-space> <c-x><c-u>
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.
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.
Well apparently you wasted your time learning an arcane command line interface from the 70s.
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."
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.
Or maybe you'll move on and it isn't that big of a deal.
You have been warned.
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.
That's cool. Also puts what I took for condescension in a different light.
Anyone used it? I might consider learning vi bindings decently if I can keep getting all the IDE goodness.
A few finer points are missing, but overall I can wholeheartedly recommend it. (missing: put last deletes in number registers)
There is also the free VsVim, though.
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.
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.
Either that or they're being manipulative, which is also a big red flag.
Car assembly line - lots of initial capital, specific to one kind of car, lots of time to learn.
Seems like a valid comparison.
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.
http://news.ycombinator.com/item?id=2938995
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.
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.
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.
Dudes on assembly lines use screwdrivers.
(It's really good, too, I use it at work.)
Saying that "editor/IDE with vim keybindings" is as good as vim. Is like saying a Honda Civic painted red is as good as a Ferrari f70.
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.
Until you have twenty files open and you can't find the right one (will happen sooner than you think, at least on largeish projects).
For extra points, learn to use hjkl and map your arrow keys to switch tabs.
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.
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).
I realize that the process of intercepting keystrokes is really OS specific. On windows you need to use hooks, on linux you need to deal with x.
Anyhow, thanks for the link. Since it is open source, I will look into it.
It gives you modal editing, all the basic vi movements and commands, and still lets you use all the power of Eclipse's standard editor features.
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).
map Y y$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.
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.
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>".
This is a test
^
This is a test
This is a test
This This is a test
is a testEdit: aha, pasting in insert mode works like this!
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.
PS Thanks everyone for replies!
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?
1. 0y$p
and
2. o<ESC>p
" 'Inside-line' operator-pending-mode mapping
onoremap <silent> il :<C-U>normal! ^v$h<CR>
onoremap <silent> iL :<C-U>normal! 0v$h<CR>Use an editor you can use right away and whose controlls don't contradicts with the rest of the software you use.
I don't believe in vim neither I don't belive in plain Emacs.
Just my 2 cents
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.
This is why I use ErgoEmacs :)
1) 'J' to join the two lines after paste
2) o<esc>p or O<esc>p
Perhaps there's an even "easier" way, but for me these keystrokes have long been recorded to muscle-memory, I don't even notice them anymore.
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>
"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 guess you just can't please everyone.
Never use the word "fanboy". It's a word used by people who hate joy.
Other people will call you a fanboy no matter what you do. Ignore these people.
You are a fan of vi. Nobody is fooled by your disclaimers: The joy shines through. This is not a problem. Advocate vi with pride!
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.
Fun article. :)
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
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.
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 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.
This time I thought I'd demonstrate exactly how.
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.
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.
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.
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).
Not full on guru videos but some learning videos:
http://www.derekwyatt.org/vim/vim-tutorial-videos/
The first answer here is excellent and only covers what vi can do and not all the bonus vim stuff:
http://stackoverflow.com/questions/1218390/what-is-your-most...
Good outline of the vim way:
http://stevelosh.com/blog/2010/09/coming-home-to-vim/
shows a lot of small techniques:
http://vimcasts.org/episodes/archive
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).
Give vim a shot and try to really give it a go.
Go check out some screencasts from experienced Vimmers or Emacsers.
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.
nmap <space> <c-d>
nmap <s-space> <c-u>
vmap <space> <c-d>
vmap <s-space> <c-u>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).
Also, old discussion on same article: http://news.ycombinator.com/item?id=151637
Been manually indenting stuff with :<line1>,<line2>,s/^/\t/ for years now, oof.
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?
Thanks..
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.
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.
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,
I'm trying to learn more about vi/m (and emacs) as I get more into Linux development, but I think a lifetime of Windows has damaged me, mentally
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.
I written this article which also might help you:
http://yannesposito.com/Scratch/en/blog/Learn-Vim-Progressiv...
Don't give up! It will pay faster than you think.
If thats the case, I am screwed
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.
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.
Anything in particular you want to ask?
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.
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.
All I want now is XCode with VIM bindings :-(
No other changes required. I don't use vim's 't' or 's' commands, so no problem there.
> Anything in particular you want to ask?
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.
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 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.
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.
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
I'm pretty freakin' happy with my setup.
1: http://elitekeyboards.com/products.php?sub=leopold,tenkeyles...
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.
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.
Reminds me of this article: http://rachelbythebay.com/w/2012/01/16/replyall/
Well played.
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).
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.
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.
One of my favorite tools is much older than me - which seems kind of weird in the current state of technology. I find it very humbling.
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.
> All of this, except the 20 minutes part. I'd hate
> to have to spend that much time with one of these
> "enlightened" editors.
"I'd hate to have to spend 20 minutes with Ruby, just let me describe my program in 'real' language please."
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
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.
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.)
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.
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.
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.
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.
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?
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.
It seems quite old to me.