Linkbait title alert. Please, please stop this crap. Article really says: n00b vim users, consider disabling hjkl while learning other movement commands.
What vim user does all their movement with hjkl only anyway? If you're going to deliberately cripple your editing habits like that, or if you're not even bother to learn other movement command at the same time as getting used to hjkl, you might as well stick to notepad.exe.
>What vim user does all their movement with hjkl only anyway?
Having used vim for nearly two decades now, my primary movement routine seems to be start with "/" and "?". In other words, jump to the approximate location using a word search and "W" or "w" as needed to the specific word, then use the hjkl or other commands to further refine the cursor's location.
> Having used vim for nearly two decades now, my primary movement routine seems to be start with "/" and "?". In other words, jump to the approximate location using a word search and "W" or "w" as needed to the specific word, then use the hjkl or other commands to further refine the cursor's location.
Young programmers should be made aware that there are now programming editors that do away with the need to think of a way to trick the program into moving the cursor where you want it to go. Modern editors respond to direct, concise keyboard entries to move the editing cursor to the desired destination. Like pressing the arrow keys. Or pointing at the destination with a mouse and clicking -- things like that.
Even ubiquitous command-line editors like Pico are easier to use than vi/vim. The reason is that Pico doesn't have vim's history to contend with, and its consequent rearward compatibility issues.
Not sure if just trolling, but if not it seems you're not very experienced yet in the use of the tools of the trade of the professional programmer. The point of using the vi interface is nowadays (and yes I know about the original reasons of the modal workings of vi...) that moving your fingers off the home row takes too much effort, let alone having to move your hand to the mouse. It's easier to drive an automatic, why do professional drivers switch gears manually? Because learning the more advanced interface gives them more control over the way the machine behaves, and in their use case, the investment in learning it pays off handsomely in the added power later. Should regular users bother to lean vi? No. Programmers? Yes.
> Not sure if just trolling, but if not it seems you're not very experienced yet in the use of the tools of the trade of the professional programmer. [emphasis added]
Guess again -- I wrote Apple Writer in the late 1970s (http://en.wikipedia.org/wiki/Apple_Writer). One of my goals was to eliminate the modes that plagued contemporary editors and attract people interested in ease of use and efficiency. Apple Writer became a best-seller because (among other things) its competition, most derived from vi, required users to switch modes.
And I can't believe I'm having this conversation over 30 years later, still trying to get people to choose more efficient tools.
> ... you're not very experienced yet ...
It's likely that I was programming -- and publishing my programs -- before you were born:
There's a difference between "more efficient" and "easier to learn". You're advocating the latter. This is not a good thing.
For example, moving around by using the search feature (at least a well-designed incremental search like Vim or Emacs) is more efficient for longer distance moves (e.g. more than a couple of lines)--it's faster and, more importantly, takes less thought and context switching.
When you have to move to a distinct part of your text file, chances are you know what the content there is. With a command like /, you directly turn that knowledge into efficient movement. With the arrow keys, you have to leave the home row and do a bunch of movements to get where you're going. You have to figure out how to turn the word you want to go to into a bunch of arrow actions. It's even more difficult of your target is off-screen.
Ultimately, a rich set of movement commands you can access without moving your hand is going to be more efficient than using the standard arrow keys. This is particularly true for somewhat semantic commands like moving by block or expression or moving to a word (the command in question here).
Ideally, you want to move around faster with less context switching. Keyboard-oriented editors like Vim and Emacs are much better at this than any other editor I've seen, as long as you learned how to use them properly. This really makes the learning curve more than with it.
> There's a difference between "more efficient" and "easier to learn". You're advocating the latter. This is not a good thing.
You've posed a false dichotomy. Modern editors are both more efficient and easier to learn.
> Ideally, you want to move around faster with less context switching. Keyboard-oriented editors like Vim and Emacs are much better at this than any other editor I've seen, as long as you learned how to use them properly.
Pico is a keyboard-only editor, and it's easier to navigate, and to use in general. So is every other editor that exists, written after about 1980. None of them require the user to switch modes, an idea that died with vi -- I mean, if only vi had died.
As soon as keyboards included arrow keys, the handwriting was on the wall.
How is a mouse more efficient than an ability to move to a phrase with a bit of typing, skip words ahead with a single letter instead of ctrl + shift, move to a new line and a specific place on that line with a couple of button presses, etc?
> How is a mouse more efficient than an ability to move to a phrase with a bit of typing, skip words ahead with a single letter instead of ctrl + shift, move to a new line and a specific place on that line with a couple of button presses, etc?
I can't improve on your explanation as the answer to your own question. Obviously using a mouse to cut/copy and paste, within the same document or between independent documents, is more efficient than what you just described.
Moving my hand over to the mouse, moving the mouse cursor to wherever I need, selecting that text and dragging while my editor slowly scrolls with my cursor when I could use a few key sequences with no context switch is the opposite of efficient.
> Obviously using a mouse to cut/copy and paste, within the same document or between independent documents, is more efficient than what you just described.
You may personally believe this strongly, but it's most certainly not "obvious"...
In reality, as is usually the case, it depends very much on the details of what's being done. Some cases are faster with a mouse, others with well-designed keyboard commands.
[Which is why good editors support both styles of interaction...]
Vi people look at me like I have a mental disability when I say this, but I've written tens of thousands of lines of code in pico; it is a completely serviceable programmer's editor.
For example, moving around by using the search feature (at least a well-designed incremental search like Vim or Emacs) is more efficient for longer distance moves (e.g. more than a couple of lines)--it's faster and, more importantly, takes less thought and context switching.
I'm no longer sure I agree with any of this.
When I move in Vim and the whole screen jumps, I have to reorient myself, and convince myself that I have jumped to the right place, and not a similar-looking-place by mistake. I have to take mental energy away from thinking about the content to think about the editor and look for a good jump command, where arrow keys are so basic that they aren't a distraction at all.
I am so glad to see someone else with perspective at least make their voice heard. This vim thing is absolute lunacy. I was booting machines from scratch thirty years ago with Forth and writing my own text editors to be able to program the machine. I used crippled keyboards without mice, function keys and cursor buttons. And I gladly said goodbye to that crap years ago.
Then you come to a place like HN and you have "youngsters" forming a cult around a shit editor with a shit interface that ignores all modern peripherals. A shit editor that would have been written in an entirely different way had the authors had access to more than A-Z, 0-9 and a few mode keys. Then they actually make themselves believe that they are being more "efficient" by using this shit editor. I guess that's no different from cults who believe in imaginary things.
As I have said before, show me one company, one project, that has some in on time, budget and without bugs because of their choice of vim over even something like Notepad and I'll eat my words.
Young HN readers need to at least be made to consider that the factors influencing the quality, success or failure of software project or startup have so little to do with your choice of text editors that it is beyond ridiculous to even discuss it.
> As I have said before, show me one company, one project, that has some in on time, budget and without bugs because of their choice of vim over even something like Notepad and I'll eat my words.
Show me one transportation company that would fail because their trucks do not have air conditioning or power steering.
Is it nice to have those things, especially if you drive around the entire day? Of couse.
I'm with you that vim should not be a cult.
But calling it a shit interface is over the top.
If it was, why are there so many popular vim emulation plugins for many of the modern IDEs.
> One of my goals was to eliminate the modes that plagued contemporary editors and attract people interested in ease of use and efficiency.
I certainly bought into this line of reasoning when I learned Emacs instead of vi all those years ago. These days I'm not so sure. Me, RMS, and most of my Emacs-using friends have developed carpal tunnel syndrome, while the people I know that use vi have mostly not. Furthermore I can feel my fingers hurt every time I have to type C-M-something or M-something C-something M-something C-something. This sort of stuff is rampant in Emacs, not to mention Eclipse and all the other IDEs that I know of, and from what I can tell of vi, seems to be less so in vi.
I have been working as a professional programmer for twenty years. I have used more text editors than I can remember; I've even written a couple of new ones. My experience has been that the editor makes almost no difference. I spend far more time thinking about code than I ever do writing it.
Vi has a terrible ancient mess of an interface designed for primitive machines in a bygone age. I believe that part of its popularity comes from a sort of stockholm syndrome effect; people who have spent the time required to master it don't want to feel that they have wasted their effort, so they assign some of the credit for their own innate productivity to the editor.
In practice, I have never seen any difference in productivity levels among my teammates based on the text editors they use. All of the professional programmers I know spend far more time thinking about code, discussing code, and reviewing code than they ever do editing code; even if vi were somehow magically able to make people twice as productive at editing code, that would still only be a small single digit percentage of productivity improvement overall. But I have seen nothing which makes me believe that people using vi are more productive even on strictly text-editing-based tasks than people using other text editors.
There are occasional situations where a vi user can do some complex macro thing that rapidly does some transformation to a text file, which someone using a simpler text editor might take longer to perform, but if your project is full of code which needs to be transformed in repetitive, brute force ways, you have bigger problems than your choice of editor.
My problem is that this power doesn't motivate me. Do I want to make lots of changes rapidly? No. Further: THAT WOULD BE BAD. I want to make concise changes based on sober reflection. Do I want a convenient browsing mechanism that stays minimal while I internalise the code I'm reading? Yes. I get the _why_ of vim, but the obsession over mashing keys as fast as you can seems like a bad smell in terms of developer attitude.
for the latter, i'm saying i'd rather navigate with a scroll wheel and hyperlinked names a lot more than i want to search multiple buffers. hands away from the keyboard, reading mode rather than typing mode, getting context
I guess some people has too look where the arrow keys are, in order to move the hand there and start using them. The same with the insert, home, etc. block. In that case, I can understand that it takes too much effort.
In my case it's like I know the keyboard better than my hand, for example hit Shift + Insert so fast that I barely perceive what I do, except because something got inserted. The same for the arrow keys (which I seldom use alone, as they do more when using a modifier key, like Ctrl).
Now to the point: please don't over-generalize, my own case proves that for some people arrow keys are fast enough.
In fact, it's exactly like switching gears in a manual transmission, which I do. After enough practice you just know where each shift is, and do it without thinking. It's a special case of spacial awareness.
However, I concede to the parent that using search (* or Ctrl-F) is much better than jumping around.
I'm not sure if he's trolling or not either. But since he wrote the original "Apple Writer", (see http://www.arachnoid.com/administration/index.html ) It seems likely that he knows something about the tools of a professional programmer.
How is using text find to move to where you want "tricking" the program? With Easy Motion that type of cursor movement becomes even easier. Using a mouse just slows a vim/emacs user down.
> How is using text find to move to where you want "tricking" the program?
It's a trick because it uses one function (locating text) to accomplish another (navigation). Modern editors don't need to be tricked into cooperating with their users.
> With Easy Motion that type of cursor movement becomes even easier.
Ah, an add-on tool to get around vim's built-in inefficiencies. Guess why modern editors don't need Easy Motion to improve their usability? The answer is that they were pre-improved by their creators, who (among other things) eliminated modes as a design goal. No modes, no need for Easy Motion.
Do you get upset when someone uses a flat head screwdriver to open a paint can? Surely that was not its intended use, but tools can be used to accomplish a larger set of tasks than the original itch they scratched.
> Exactly, but it isn't just vim and emacs. Using the mouse is terribly inefficient for any typing-oriented endeavor.
That depends -- how far do you need to move, and how much text do you need to select? For large moves, and for large text selections, using a pointing device is often much easier than using the keyboard. Modern editors auto-scroll to keep the mouse cursor in view, which means I can select an arbitrary, and huge, block of text in seconds. And I do, regularly.
Shift + page down allows you to select entire pages of text, cut it, and move it to whatever other position. It's also probably faster given that autoscrolling moves at a slower speed than page down.
Sure, but now you're utilizing the keyboard and mouse together, and, as you said, it isn't necessarily faster. That's an argument for sticking to the mouse. It's mostly justification. It isn't an argument in favor of consistently preferring the mouse to the keyboard.
I somewhat agree with you. Which is why I use macVim. for editing and getting places you want, nothing is faster or better than vim (In my humble opinion). But sometimes my dumb ass has no idea where to start or what I should be looking at, so I need need NEED a nice scrolling feature and mouse click actions from my trackpad. some simple mindless hand movements combined with using my eyes to read is a million times faster for me than any kind of key combo if I don't know where I'm going.
I'm sure you've heard of the EasyMotion plugin. If you're like me, you probably found it to be overkill. I made a fork that limits the EasyMotion effect to the current line (with some slight adjustments), and my efficiency navigating the current line has increased dramatically. I encourage you to give it a go
> Moving your Vim cursor around using the arrow keys is a bad habit ...
Yes, as is having a keyboard with more than 64 keys, a pointing device, software that allows character insertion, deletion and cursor motion all without changing modes, or any computer designed after 1980. We must all fight against this rising tide of convenience and efficiency by insisting that everyone use vim and its descendants.
Being "anti-vim" is perfectly alright with me. I use vim because it's the fastest thing I've ever used by a very wide margin. I also respect others who find it too hard to learn or find they're more productive elsewhere.
But a comment that essentially boils down to "vim is archaic" in a post about vim usage habits is totally ridiculous, so in the nicest way possible, get lost.
Yes. However, I would point out that eventually this productivity thing matters i.e. more productive developers will be able to effect more change in the world faster than less productive developers.
While I'm all for sharing knowledge, if my competition is putting creative effort into hobbling themselves, then I say leave them to it.
> I use vim because it's the fastest thing I've ever used by a very wide margin.
I used to think this, but then I paired with someone who was eye-wateringly fast with TextMate (that person has since converted to using vim full-time). Rather than speed, for me at least, its always been about fluency (how little cognitive load is there between thinking and the code appearing). I happen to be a lot faster than most IDE clowns I happen to be working with, but I believe that's a happy side-effect.
> But a comment that essentially boils down to "vim is archaic" in a post about vim usage habits is totally ridiculous ...
And entirely topical. Young programmers who read such posts may not realize how many more efficient options are now available. Speaking about vim as though it's an obvious choice in 2013 would be like insisting that everyone code in Fortran in 2013.
You're commenting on a vim post in order to help lost young programmers understand that there are other options besides vim?
Speaking about vim as though it's an obvious choice in 2013 would be like insisting that everyone code in Fortran in 2013.
Oh, now talking about how to use vim effectively is like insisting that everyone uses an archaic programming language? I suppose if we were to have a post here talking about how to use the command line effectively, you'd feel obliged to educate young programmers that we've moved on from the 1970s.
> You're commenting on a vim post in order to help lost young programmers understand that there are other options besides vim?
Yes, and what better place?
> Oh, now talking about how to use vim effectively is like insisting that everyone uses an archaic programming language?
Based on the number of objections to a discussion of vim's alternatives, yes -- that's a legitimate comparison.
> I suppose if we were to have a post here talking about how to use the command line effectively, you'd feel obliged to educate young programmers that we've moved on from the 1970s.
Only in the midst of an amazing discussion that included various "cheat-sheet" strategies to get around the behaviors of an editor that demands cheating to be productive. Given that context, saying that newer editors don't require you to cheat seems entirely topical.
> I would really like to know what options are there that are more efficient than VIM for text editing...
In answer, I have to say that nearly every other text editor that exists is more efficient than vi/vim. Modern editors are mode-free, meaning (don't faint) you don't have to change modes to insert, delete and navigate. These editors don't need "cheat sheets" to help you figure out how to switch modes and navigate, because you don't have to cheat.
Vi/vim is the oldest editor still commonly available. I used it in the 1970s when I worked for NASA, on a "paper terminal". In that environment, its quirks made sense because they saved paper. Since then, it has been completely superseded by newer, better programs.
Even my now-ancient program Apple Writer (http://en.wikipedia.org/wiki/Apple_Writer) was easier to use, largely because my program addressed and solved some of vi's more annoying problems. There's a reason Apple Writer became a best-seller -- one of them was that fact that, by eliminating modes, it represented a huge improvement over existing editors, including vi.
But that was the early 1980s. If I had been told then that I would still be trying to get people to use more efficient editors over 30 years, later I would have laughed -- impossible!
First, I don't know vi. Well, I am aware that something like this exists, because I see "{not in vi}" everywhere in VIM docs. So maybe you should familiarize yourself with VIM before talking about it - for example I noticed that you wrote that "[in modern editors] there is no need to wonder in what mode you are" as if it was a problem in VIM. It's true for vi, but VIM has a mode indicator on a status bar since times immemorial.
Second, in VIM there are three modes, that's true, but not the ones you enumerate. There is: insert mode, normal mode and visual mode. All modern editors have at least the last one: the editor (all of them) behaves differently when you have some text selected.
Third, in VIM you can freely delete and navigate (with arrows!) in insert mode. No problem at all. Even things like ctrl+left for to skip a word backwards work.
Fourth, sheer amount of commands and functions makes the cheatsheets you mention valuable, they are not needed because the functions are so weird, they are needed because there is so many of them. I saw cheatsheets for Word and Photoshop too. You could argue that paint is better than photoshop because you don't need a cheatsheet to use it, but I doubt you'd want to do that. It's the same for editors: you don't need a cheatsheet for notepad...
Fifth, VIM evolved to the point that it is effectively a platform for building text processing apps, similar to Emacs. There's VIMScript and Python, Ruby and Lua support. With this there is practically no limit to what you can make VIM do for you.
To summarize: you seem to mistake VIM for vi; please take a closer look at modern VIM and then come back with a critique that makes sense in 2013.
> It's true for vi, but VIM has a mode indicator on a status bar since times immemorial.
That's a nice improvement -- an indicator to tell you which of the three exclusive modes you're in at the moment. But imagine this -- imagine eliminating both the indicator, and the modes, all in one fell swoop, as modern editors have done.
> ... please take a closer look at modern VIM and then come back with a critique that makes sense in 2013.
When I wrote Apple Writer in 1978, I rendered vi/vim obsolete (and my program became a best-seller based on its ease of use). Among other things, Apple Writer didn't either have or require modes. Neither have any more recent editors, all of which had to compete with Apple Writer or its descendants.
"imagine eliminating both the indicator, and the modes"
I was using modeless editors all my life; I was working with Zend Studio and Komodo IDE which are definitely modern editors. Yet I chose to have modes and switched to VIM. In other words I have no problem with imagining editors you talk about, I just don't like them.
"When I wrote Apple Writer in 1978 ..."
That's a funny thing, because VIM appeared in 1993 and only really became what it is now around 2006. Whatever you did deprecate, it was not VIM.
With all due respect, you seem to know next to nothing about modern VIM. You didn't use it, right? I am using it every day and I can compare it with several other editors and I can assure you that VIM offers nearly everything other editors do inside the insert mode - you can work never leaving it, then it's like it was modeless - and that normal mode is an additional feature that accomplishes things not possible in other editors at all.
Anyway, I'm alright with you convincing people not to use vi. It's archaic and cumbersome, has many missing features and so on. On the other hand, please stop bashing modes - it's ok that you don't like them, but that's your personal choice - and stop including VIM in your rants.
> That's a funny thing, because VIM appeared in 1993 and only really became what it is now around 2006. Whatever you did deprecate, it was not VIM.
I identified my subject very clearly. Are you really unaware that vim derives from vi, and contains the same core code and strategy? That a discussion of vim is a discussion of vi? But let's allow Google to decide this for us:
Search for "vi/vim" : "About 482,000 results" ... Q.E.D.
> On the other hand, please stop bashing modes ...
You won't get far with this as an argument. All modern editors bash modes by not having them (the sincerest form of unflattery). Not one editor written since 1980 has used modes (except vim, of course), because they're an idea whose purpose has vanished.
> and stop including VIM in your rants.
Vim is vi brought back to life -- old wine in a new bottle.
VIM is the de facto vi on many platforms, I suppose that this is the reason for your search results.
I agree that VIM derives from vi, it's obvious - my point, however, is that the additions and improvements and changes in VIM are many times larger (in terms of code and "user facing surface" like commands) than the core itself; and that essentially creates a new, separate product. Take MS DOS and MS Windows 95 as an example - IIRC Win95 still ran under DOS, yet it exposed completely new APIs and model of user interaction. Would you say that discussing Win95 means discussing DOS? Would you say that Win95 is the same as DOS?
As for modes - I didn't want to get into this - you seem to be convinced that having modes is a bad thing. Your argument is that "every other editor is modeless" - and it's false. The truth is that almost every modern, serious editor includes vi emulation mode and hence can work in a modal fashion - from Visual Studio to PyCharm to SublimeText all of them have an option to have modes. So your argument is simply wrong.
Is modal editing objectively worse thing? I don't believe so. I think that, while introducing some overhead for simple commands (one additional key press for changing modes) it significantly simplifies complex things, because you don't need modifiers and chaining commands is easier.
As for VIM being vi brought back to life - see Win95 argument above.
> and that essentially creates a new, separate product.
New, yes, separate, no. Vim has the same modes, the same handicaps, as its predecessor.
> As for modes - I didn't want to get into this ... (long discussion of modes)
This reminds me of a famous and very funny monologue in "Five Easy Pieces" in which a woman talks endlessly about some truly boring topic, punctuated with "But I don't want to talk about it" over and over again. It's priceless.
> Your argument is that "every other editor is modeless" - and it's false.
It's true. Apart from the occasional editor that ridicules vi by including a vi emulation mode, just as a comic riff for modern programmers who aren't aware how bad things were and how far they've come ...
> The truth is that almost every modern, serious editor includes vi emulation mode
... ah, so that's what you were talking about. Obviously an editor that includes a vi emulator mode can't be accused of requiring what vi requires. Or don't you see that?
> So your argument is simply wrong.
Hospitals are equipped with wheelchairs and crutches -- does this mean that's their goal? No, it means they realize something may go very wrong and they want to be prepared.
The reason for vi emulation mode is to accommodate people who are beyond meaningful retraining. Have you heard that you can't teach a dead dog new tricks?
What I find shocking is that new programmers will start learning vi/vim without realizing how primitive it is by modern standards. This thread can only perpetuate the fantasy that vi/vim is anything but a way to avoid abandoning older programmers and their skill set entirely.
> Would you say that Win95 is the same as DOS?
Does it still require drive letters? There's your answer -- drive letters stand for (but doesn't exhaust) all the things that are wrong with Windows. By the same token, requiring mode switches stands for all the things that are wrong with vi/vim.
> These editors don't need "cheat sheets" to help you figure out how to switch modes and navigate, because you don't have to cheat.
I haven't used a cheat sheet with vim in years now. I don't think I used a cheat sheet after a month of using vim. `:w` is as natural to me as ctrl-s. Slightly more natural, because I don't have to think in order to turn a save into a save as, if I want to write the contents to another file.
And if we want to talk cheat sheets, wouldn't you consider menus in non-modal editors to be cheat sheets, since they show both the keyboard shortcut, and the action, side by side?
Yep. And it is two keystrokes instead of one. Wouldn't it be more efficient to eliminate one of those keystrokes rather than committing them to memory? That's the approach taken by all editors written since about 1980, so it seems to be an idea whose time has come -- and passed.
> And if we want to talk cheat sheets, wouldn't you consider menus in non-modal editors to be cheat sheets, since they show both the keyboard shortcut, and the action, side by side?
The "cheat sheets" I refer to are those that map multiple-keystroke sequences to the actions that, in a modern editor, require one keystroke.
Technically, it's three keystrokes instead of two. And you have to commit ctrl-s (or cmd-s if you're on a mac) to memory just as much as you do :w. Nothing really saved there.
> The "cheat sheets" I refer to are those that map multiple-keystroke sequences to the actions that, in a modern editor, require one keystroke.
Like delete the next four words? How do I do that in a modern editor with a single keystroke? How about "replace everything inside these quotes"? Or repeat the last action I just took again?
I'm glad you like your modern editors (there's lots there to love), but they are not inherently better than vim just because they're non-modal. There is typically a more shallow learning curve than VIM, but the simple virtue of being non-modal doesn't guarantee that (sorry, Emacs).
In the end, two things sealed the deal for VIM for me. 1) it's on every remote server I have to access, and 2) I've put the time into it, so I'm quite efficient in it.
In my last job, since I was only doing local development, I tried out Sublime Text 2 for a good 3 months before giving up on it. I was constantly thinking "I know how to do this in vim - how do I do it here?", and ultimately, I got tired of constantly reaching for the mouse for trivial things like selecting and moving text. I felt that 3 months was sufficient to really give ST2 a fair shake, so I didn't (and still don't) feel bad when I went back to the terminal.
> I'm glad you like your modern editors (there's lots there to love), but they are not inherently better than vim just because they're non-modal.
Yes, in point of fact, they are better than vi/vim because they are non-modal. When all is said and done, dropping vi's modes makes an editor better and more efficient.
> Like delete the next four words? How do I do that in a modern editor with a single keystroke?
You can't delete four words with a single keystroke. You can delete [N] words, but only after switching modes and choosing the desired number.
Quote: "ndw : Deletes the next n words starting with current"
The above assumes you're already switched to the required mode, so a minimum of four keystrokes if the number [N] is a single digit. Then, to continue typing, you have to switch back to the mode you started from. Total five keystrokes minimum.
> In the end, two things sealed the deal for VIM for me. 1) it's on every remote server I have to access, and 2) I've put the time into it, so I'm quite efficient in it.
This is circular reasoning. The reason vi or vim is out there on all those servers is because of the number of people who haven't learned anything else.
You were the one who claimed all the multi-keystroke shortcuts were possible in one keystroke, not falcolas.
Plenty of us switched to vim after using mouse-oriented editors for years or decades. Why are you so offended that we have different preferences than you?
> I'd love to hear those many more efficient options!
This may come as a surprise, but modern programming editors don't require the operator to switch between three mutually exclusive modes -- insert, delete and navigate. That's because modern keyboards have keys dedicated to those purposes, which means the operator doesn't have to either wonder which mode he is in, or switch modes, which saves an enormous amount of time when programming.
The first step toward modern editing is use of the arrow keys for navigation. The next step is to realize, if the arrow keys can reposition the cursor without using letter keys, then maybe there's no reason to have to switch modes.
Vim's focus on keyboards that no longer exist, and on displays that no longer exist (including the paper terminal I used with vi while working for NASA forty years ago), requires an incredible number of unnecessary keystrokes, as exemplified in this typical conversation:
> This may come as a surprise, but modern programming editors don't require the operator to switch between three mutually exclusive modes -- insert, delete and navigate. That's because modern keyboards have keys dedicated to those purposes, which means the operator doesn't have to either wonder which mode he is in, or switch modes, which saves an enormous amount of time when programming.
You speak as if modal editing came first and universally agreed upon better things evolved afterwards. I know this isn't true. I know you know this isn't true. You're being highly disingenuous.
Your link is equally disingenuous since you either don't understand that the operation involved there is not one you can do in-stride or with as few keys in any other "modern" editor, or if I give you slightly more credit but presume malice then you're being willfully misleading again.
> You speak as if modal editing came first and universally agreed upon better things evolved afterwards.
That's exactly what happened, and think before objecting, because I was there. I used vi while working for NASA during the 1970s, when mode changes made sense (it saved paper on paper terminals). Since then, it has stopped making sense.
> I know this isn't true. I know you know this isn't true. You're being highly disingenuous.
When I wrote Apple Writer in the late 1970s, I suspected it would become popular because it eliminated the modes that plagued most contemporary editors including vi. I was right -- it did. Apple Writer became a best-seller because people hadn't yet realized that modes and mode switching were pointless burdens in a era of glass terminals and extended keyboards.
I can't believe there are people who haven't learned this elementary lesson now, over 30 years later.
> I can't believe there are people who haven't learned this elementary lesson now, over 30 years later
Why would you let something like this bother you? There are many popular text editors and IDEs in the world, and of all these myriad, there is only one popular editor that is modeful: vi. Why would you begrudge the people who prefer to do their editing modefully, a single editor that does things this way?
It's not like vi is going to corrupt the yout's of today, as the yout's are fully exposed to IDEs such as Eclipse, IDEA, Xcode, and Visual Studio, all of which are modeless, not to mention Word, Pages, Google Docs, etc.
Modal editing did come first, and universally agreed upon better things did evolve afterwards. I remember "modes are bad" being established UI-design wisdom as long ago as the mid-'80s, after the Macintosh came out and everyone started moving toward graphical interfaces. I'm surprised there is anything about this question which is seen as being open to debate here in 2013.
And no, universally agreed upon better things did not evolve afterwards. I have no idea what the numbers are, but Vim is immensely popular amongst developers and I would highly suspect more popular amongst experienced developers than any editor whose name isn't emacs.
You are deluding yourself if you think that the modern world uses modal editors because their ancestors had keyboards that were too cramped.
That's not the operation from the question in the link (not that I'd be terribly surprised if Sublime Text had a way to do it anyways, but it's not as fluid as vim).
I use both vim (over ssh) and modern GUI programming editors on a regular basis with extremely large code bases. I am thoroughly familiar with the the various navigation shortcuts available to me and (at least for me) find that navigating and editing source code in vim is still faster by a large margin compared to modern editors that have the convenience of modeless editing.
That's not to say that modern editors don't have their advantages but I think it is a bit of a stretch to argue that modern editors are substantially better at editing text than vim.
> I think it is a bit of a stretch to argue that modern editors are substantially better at editing text than vim.
Yes, well put, except it's true -- modern editors are much more efficient at editing large code bases than vi/vim. None of them require a "cheat sheet" of keyboard arcana, for the simple reason that to use a modern editor, you don't have to cheat.
It gives one pause to consider that Pico, the tiny, throwaway command-line editor, is easier to use than vi. The proof? It has become the default choice when someone wants to save time.
I disagree that Pico is easy to use. The only way to move around within a line is to hit the arrow keys sixty times. By default, cut and paste works on whole lines only. If you want to cut just one word you have to figure out the commands for select mode.
I spent a good while reading your replys and one of the things you keep saying is cheat sheet. Now I dont use a cheat sheet because my fingers have become accustomed to the way vim works. The other thing you are saying a lot is that it takes time to switch modes. It does not. For most people you have to move your fingers off of the home key row to click delete or control so it is easier to just use the keys closer saving lots of time. The other thing you said is that modal editing has become obsolete which is simply not true because almost every IDE comes with a VI(M) mode and is not restricted to the non modal form. Also you say that hjkl are inefficient you have to move your entire hand to use the arrow keys but with hjkl you just have to keep it in the same place.
Then I shall be clearer and say that I disagree that vi/vim is harder to use than an editor that needs a command-line flag to enable search-and-replace and doesn't do case-insensitive search at all.
But Vim's not just hjkl. And all those new keys don't exactly help me get stuff done faster.
Sure those F-keys can be useful. If I'd like to change the screen brightness or skip to next song.
Pause/Home/Insert/Print... Half of the time they don't do anything the other half they don't do anything useful. And then there are a bunch of keys that toggle a light and change the behaviour of keys to annoy everyone. Because switching the num block from one duplicated set of functionalities to another greatly increases the available keys!
No wonder 'modern' editors use so many shortcuts. There are simply far more useful functions to perform than keys. Most newer editors go the emacs way and make you press a bunch of modifier keys. Vim makes you go through modes. I prefer to hit easy to reach keys multiple times, but to each his own.
Please see http://vimgolf.com/ and let me know if you still believe Vim requires and incredible number of unnecessary keystrokes. Some of the editing you can do with so little keystrokes is amazing!
> Please see http://vimgolf.com/ and let me know if you still believe Vim requires and incredible number of unnecessary keystrokes.
But that site's purpose is to show how clever people have become in fighting vim's innate inefficiencies. If someone posted to that forum using a modern editor, he would be thrown out for cheating, for suggesting that there's a better way.
I use vim for some things (mainly script and minor XML editing) and IDEs for other things. I would never attempt to develop a big C, Java or even Ruby (after trying RubyMine) system in. Stuff that refactoring, finding usage-of and looking at call-hierarchy are some of the things that are either only done in a 'patchy' way or non-existent in Vim.
It really doesn't have to be dogma, stuff like this can really help building a habit especially if you use it every day.
I had this problem when I used to play Counter Strike Source. I was weapon switching with the scroll wheel which is just terrible, and since it is a shooting game I was getting shot because in a tight spot I couldn't pull out my pistol fast enough. So I just unbound the scroll wheel for a couple weeks and then using the number keys instead was natural, and now it doesn't matter if the scroll wheel is connected or not, I reach for the numbers first.
So after you fix the habit you can put the mapping back and still have it available.
Totally Unrelated: I read most of your book about sailing (most I think, you're in the Mediterranean,) and I've enjoyed it, cheers.
> It really doesn't have to be dogma, stuff like this can really help building a habit especially if you use it every day.
Yes, but in modern times, the habit of navigating with arrow keys is a more transferable habit to develop. Assuming we use more than one program in our work.
And almost no programs retain the archaic i/j/k/m navigation scheme -- not surprising, since those are letter keys and most modern programs don't require the operator to switch modes in order to move the cursor -- and why should they? A modern keyboard has dedicated keys for that purpose.
> I read most of your book about sailing (most I think, you're in the Mediterranean,) ...
Thanks -- well, I did have to sail the remaining half distance around the world from there. :)
I have a keyboard with 68 keys (I don't count the auxiliary rubber buttons), which is nice because I can reach them all without moving my hands from the home position. I call this convenience and efficiency.
I have a pointing device that I like a lot for some purposes, but I don't use it for core work, since that revolves around manipulating a bunch of symbols found on the aforementioned keys, and not found on the pointing device. I call this convenience and efficiency.
vi and its descendants — actually TECO and its descendants — don't actually have ‘modes’ in the sense suggested. They have functions with arguments, and certain rules for combining these functions. What this article is trying to point out is that some of these functions take advantage of the correspondence between the symbols being manipulated and the symbols literally at the user's fingertips. I call this convenience and efficiency.
This isn't about being some old fogey who's stuck in the 80s. It's good ergonomics to avoid hand movements away from the home row to the arrow keys or the mouse. My wrists have felt significantly better since I went cold turkey on the arrow keys.
Same here, and I type dvorak. The hjkl keys are in a completely different location on a dvorak keyboard as opposed to qwerty, and yet I have seen a reduction in wrist pain.
It's really, really hard to customize because some commands are mapped according to their position (hjkl) and others are mapped according to their initial ("y" for "yank", e.g.).
Trying to keep both is thus impossible, as there are collisions. So your options are:
1) Preserve position, and remap everything back to its qwerty location. Downside: you have to train yourself that you're not pressing "n" for next, you're pressing "k".
2) Don't remap anything. Downside: nothing is ergonomic anymore.
3) Keep positional keys in their correct position, assign mnemonic keys when they don't collide with the positional keys and choose new mnemonics when there are collisions. Downside: only you can ever use your vim.
The best support I saw was for #3 but it ended up being a deal-breaker since I pair program (but that's OK, because using colemak itself ended up being a deal-breaker since I pair).
I also switched to colemak but things are still good in vim.
You got your n key under your right index finger, and I use searching for long range jumps. Vim was designed for qwerty not colemak, so you do have to compensate in some areas but I feel that just the efficiency colemak provides to typing english makes up for it.
J and K are the C and V keys respectively, and H and L are the J and P keys respectively - so it's not too bad, though hardly ideal. My use of a dvorak keyboard is probably why I never bothered with H and L when using vim, and only very rarely used J and K. I just used the arrow keys, if I wanted to move one cell at a time.
(I never really saw the point of trying to make people use hjkl for cursor navigation. You should try always to use higher-level navigations commands, and if you move cell by cell, you've lost already! - so there's nothing wrong with using the arrow keys for it rather than hjkl. That is, after all, what the arrow keys are there for.)
I did remap the keys at first but found that the hjkl layout for dvorak is not at all uncomfortable. I frequently jump between disparate *nix systems, and for most part use the canned nvi in preference to vim. I try to do most of my work with as generic a vi keyset as possible. Multiple screens, etc, are handled with tmux (or with screen if its the only thing available). Dvorak is defaulted on my local workstation, and as I connect through a terminal emulator, the host unix box does not know or need to know that I run dvorak or have my terminal set to amber and black, etc. In short, I try to make myself comfortable while avoiding tinkering whenever possible.
No kidding. I spend a ton of my day in Vim and use the arrow keys because I like them. That's the only reason: I've tried hjkl (I mean, I've ascended seven times in Nethack, I know hjkl) and I don't like it. I even use motions...with the arrow keys. I have a Mac and the arrow keys are all of three and a half inches from the home row and I do not have the little blob in the back of my brain that lights up with pain when I am performing a trivial operation in a more mentally consistent but less optimal manner. (The time it's taken to write this post has probably outstripped any optimization I'd get for using hjkl...yearly.)
I don't do use hjkl out of concerns about optimality, personally. I do it because I find moving my hand back and forth from the home row to the arrow keys is hard on my wrists, and I get tired sooner. I've found that coding is a lot less hard on my hands since I started using the traditional vim way of doing things, but YMMV of course.
I'm sure that's true for some folks, yeah. For me, I find it to be less of a concern since moving to a laptop keyboard (less distance to move, forced me to stop pounding the keyboard) and working at a standing desk a lot more. Those seemed to address the deeper causes of my ergonomics issues.
I think you end up wasting time deciding what combinations of w, b, e, f, F, t, T, h, j, k, and l you need to type to get you to the right place. Then you feel really good and efficient because you hit "just a few keys" and got where you wanted. Meanwhile, I took 2 seconds to grab the mouse, click where I want to be, and return my hands to the home row.
That's not to say Vim's keyboard capabilities aren't useful--they are! Sometimes you just want to move a character over, sometimes you need to justify a paragraph (gqap, or |fmt). But I'll contend that in general, when you want to move to a point in the text, using the mouse pointer to point where you want is the easiest.
When I need a shopkeeper to grab something off the shelf (maybe my favorite dirty magazine, I don't know), I don't say "ok 3 rows down from the top, 7 columns in, no sorry one more column to the right, that's it". I point and say, "I want that one".
Sure. And don't get me wrong--I use them! (Though I will admit that also use that touchy-pointy thing that's bolted on below my spacebar for getting around too, which I never did on Windows or Linux.) But when I need to move character-by-character, for me, it makes way more logical sense to use the things with the left, right, up, and down marks on them because that's what they're there for. hjkl doesn't make sense to me, so I don't use it.
(Something like HJUK--or even just WASD--would make more sense to me, but I don't care enough to start remapping all the live-long day.)
Fewer keys and being old aren't arguments against something being convenient and efficient... See for instance the benefit that 22 keys can have with a stenotype machine: http://en.wikipedia.org/wiki/Stenotype Should everyone learn to use one? Probably not, but if you're invested already it wouldn't be prudent to ignore the advice of those already familiar with the device. Similarly with vim.
This is so true. The basic error the article makes is equating number of keys typed with efficiency. Not all key presses are equal. When you navigate with letter searches you have to think much more than holding down an arrow key until you're at the point you want to be, or even better moving your mouse pointer. Fingers are quick, brains are slow. Especially when you are already using that brain at full capacity for the programming task itself.
I for one welcome touch screens for programming, which are even better than a mouse (touch screens are of course not a good replacement for a keyboard, they are however a good replacement for a mouse for many tasks).
I've been a VIM hater for years but I'm really enjoying it recently.
Mouse works, scroll wheel, arrow keys work even in terminal.
It's really about switching files, navigating by class/definition, and 0 latency GUIs. ZERO. No excuse for having to wait for your computer when you are just editing text files.
Sublime Text is pretty fast but still I'm often waiting for it to build a new tab or format search results. Eclipse is unusable.
More importantly, why don't we have eye tracking so we can just look and start typing ? Maybe leap motion can get us there.
I can see the point only so far as disabling the keys temporarily in order to force yourself to learn and use some of the more powerful key combinations.
But, I had to deal with hjkl on dumb terminals either without arrows, or with arrows that didn't work. I always hated it. The arrow keys I find very obvious, simple and effective.
If anything, you're the one arguing for outdated editors -- editors that are not aware of structure and treat programs like an array of characters, allowing navigation only by the simplest and least efficient means possible.
The other stuff you mentioned at least has upsides. Moving your hand over to the arrow keys does nothing that hjkl doesn't, and it's slower. There is literally no upside.
It's amazing how fast you can retrain muscle memory by disabling certain keys. It's frustrating for about half a day, then kind of annoying for a day or two, and then you've completely retrained yourself. In just a day or so!
However, I like to fiddle with the cursor while I'm thinking. Might be just me. I don't like feeling like I'm completely constrained. It's nice to casually move around when I'm pondering something deeply.
When I'm seriously coding though, I almost exclusively use move forward/backword by word or expression, and then use ace-jump to arbitrarily jump to specific points (http://www.emacsrocks.com/e10.html). I use Emacs of course.
> I like to fiddle with the cursor while I'm thinking.
That's a good point - I do that too. Also, if I've switched my attention somewhere else, then back to vim, I find myself doing "hlhlhl" to get my attention back to the cursor immediately.
Oh please, not vim again. Now you are not even supposed to use the already ridiculous hjkl mappings. It's really amazing to me to see this sub-culture attach itself to an editor that was designed as it is BECAUSE THE AUTHORS DID NOT HAVE KEYBOARDS WITH MORE KEYS ON THEM!
"hjkl is faster than reaching for the cursor keys". Holy frigging crap! Really? You are so good as a developer that MILLISECONDS make a difference? It does not take you hours to come up with algorithms or program structures to solve problems. And, when you do, you write code at blinding speeds (using vim) with NO BUGS, therefore MILLISECONDS matter because you are not one of those programmers who will need to spend HOURS hunting down and fixing bugs. Oh, yes, and 100% of your time is spent coding. You don't lookup documentation and you don't do any file management at all. You are a damn coding machine who can actually measure productivity by the millisecond and who must absolutely use the shittiest possible UI in the context of modern hardware to shave milliseconds from your every keystroke. You never reach for your iPod to look for music or read through HN, Facebook or even your email throughout the day because that wastes minutes. You never take a break, shoot the shit or theorize and ponder with your coworkers because you measure your life by the MILLISECONDS of flight time difference between the hjkl keys and the up, down, left, right keys 12cm away.
Right. The reality is that this is just a "I belong to the club" delusion that has nothing whatsoever to do with being a good programmer, writing good, clean, usable, extensible, reusable, fast, efficient and bug-free code. It has nothing whatsoever to do with delivering a product anyone wants and doing that on time and on budget. It has nothing whatsoever to do with being an entrepreneur, building a company, paying the bills and delivering value to users and investors alike.
It has everything to do with being a complete child and refusing to understand that there are places where you could optimize your time and energy that represent, without exaggeration, PRODUCTIVITY GAINS IN THE ORDER OF MILLIONS TO BILLIONS OF TIMES GREATER than the time required to reach for arrow keys or, Darwin forgive, the MOUSE (yes, he used that word) a few hundred times per day.
A lot of people who don't understand what vim is before criticizing it seem to miss the point that vim doesn't make you faster at writing code. Insert mode is a dumb text entry mode like any other, and Visual Studio and Textmate in fact have out of the box more tools for snippets and auto-completion than most vim users care to even supplement with plugins. Because the power is in editing text, not writing it. And oh, how convenient, programmers spend like 10% or less time writing and a whole lot more reviewing (moving around) and editing code.
I'll tell you when and why I use vim and how I can justify its useage: Linux servers. I use vim on my servers to edit everything. Why? Because I know it's there and I don't have to install anything. And, even though I think it's a horrible UI that could only be justified in an era with keyboards that barely had characters and numbers, I use it.
A religious attachment to vim? No friggin way. No editor has ever caused one of my projects to come in late (or early). The factors that affect real projects are so far removed from the software one uses to edit code that it is incredible some people evangelize something like vim to such an extent.
The other really funny thing is to see articles and blog posts describing how to add trees, tabs and all manner of other things to vim and how this makes it even cooler. Really funny.
I agree with the usefulness of Vim on Linux servers. I would say that everyone is different in how they approach their work and in the case of software development, the tools they use.
I wouldn't consider it funny that someone would want to optimize a very important tool to make it more functional. The tools we use for software development are both a curse and a blessing. A curse that there is no ONE TRUE WAY of doing something and a blessing that we can build and mold the tools to accomplish what we need.
I am not religious about Vim or any other text editor but I can definitely appreciate others wanting to optimize their usage.
Personally, I find that once you have setup Vim the way you want, its pretty much on autopilot. I would say that if someone is a natural tinker, Vim is the best black hole one can get into as there can be no end to the tinkering.
Yours is an absolutely reasonable non-fanatical position on this topic. No issues whatsoever.
My blood pressure goes up when people start to get religious about this stuff. Some go as far as proposing that one can only be a professional programmer if one uses vim, which is utter nonsense.
Well you've come off as quite the extremist shouting to the rooftops that people shouldn't try to be super efficient with vim. People who might not go out on a limb to say everyone should do it too. As for your comment on tabs and trees, sorry, those are heretics. True vim followers use buffers only.
> Well you've come off as quite the extremist shouting to the rooftops that people shouldn't try to be super efficient with vim.
That's the point. vim does not make you super-efficient at anything other than being a data entry clerk. That's not where significant value is developed in a technology business.
> True vim followers use buffers only.
Don't forget a Lear Siegler ADM3A terminal over a 300 BAUD modem leased line to the mainframe. Oh, wait, that's the way it was when vi was written.
:-)
I love this quote from Bill Joy: "I think if I were going to go back—I wouldn't go back, but start over again."
So your point is that because you may take breaks during the day, you shouldn't bother taking the time to learn sharp, efficient tools?
There are plenty of legitimate gripes to be made about vim, but you really should consider taking the time to learn a serious programmers editor like Vim or Emacs. That would at least help you avoid looking like a fool by ranting about things you clearly don't understand.
> That would at least help you avoid looking like a fool by ranting about things you clearly don't understand.
Let's talk about being a fool and talking about things I don't understand.
I have started (and self-funded) at more than three technology businesses in my life. I am in the process of starting two more.
In all cases these businesses started in my garage (one actually in my closet, before I had a garage) and managed to grow to the point where I got them out of the garage and actually hired many people.
Some of these businesses shipped product internationally, all over the world.
All of these businesses were hardware and software businesses.
Some succeeded and others failed.
And, in every single case, different technologies and tools came into the fold.
In no case whatsoever --not one-- across THIRTY YEARS of entrepreneurship did a fucking text editor have anything whatsoever to do with the success or failure of the enterprise or project.
Across a wide range of languages and technologies: machine language (actually typed-in code with a hex keypad), assembler (various processors), Forth, C, APL, C++, Fortran, Visual Basic, Lisp, Python, PHP, JavaScript, Objective-C, Verilog, 8080, 8085, 80x86, PDP1104, 6502, MC68K, PowerPC, Xilinx FPGA's, PC, Mac, Linux, embedded, workstation and server software and a few other things I probably don't remember doing.
Not once. Not ONE TIME. Have I experienced a situation where using something like vim would provide any advantage whatsoever.
And, yes, I use vim on my Linux servers because it's there. I don't have to think about it. It's the tool that comes with the box and I use it. From there to actually CHOOSE to use vim everywhere for coding our projects and to go past that and evangelize vim? That would be insane. There far more moving parts and issues in a business or in any piece of software for a text editor to make any real difference whatsoever. You can go on believing it does. And that's fine. That's not going to make it any real than believing in the tooth fairy.
Show me a real project and a real business that came in on-time, bug-free, profitably and ahead of schedule BECAUSE OF vim and I'll gladly eat my words. Because I actually happen to know what I am talking about I can say with absolute confidence that the whole thing is a big smelly pile of bullshit. If the authors had the tools, keyboards and peripherals we have today vim would have been completely and utterly different. Do you honestly believe that these guys CHOSE to have modes because of some divine revelation? No, they didn't have the friggin keys and needed to come-up with a solution. The same reason Wordstar had shit like Ctrl-K-X.
you've boiled the whole argument down into whether a text editor is the pillar upon which a successful product is built. Well of course not! Nobody is even claiming that. Some people are merely expressing it allows them to put thought onto paper a little quicker, or that they just enjoy it. Others just enjoy being able to tweak their editor, it's a fun meta activity for any programmer.
It's fine that it might not be the most optimal way to spend your time, or that you don't get it. but relax already
"machine language (actually typed-in code with a hex keypad), assembler (various processors), Forth, C, APL, C++, Fortran, Visual Basic, Lisp, Python, PHP, JavaScript, Objective-C, Verilog, 8080, 8085, 80x86, PDP1104, 6502, MC68K, PowerPC, Xilinx FPGA's, PC, Mac, Linux, embedded, workstation and server software and a few other things I probably don't remember doing."
For all that name dropping of the vast and expansive techs you've worked with, you seem to be extremely close minded on this issue.
I think he's encouraging people to focus on more pressing problems. I think he's angry because there is a silly and opinionated subculture surrounding a text editor. He exploded likely because this article - while innocent as it may be - broke the camel's back. For a site so focused on the hacker mantra of getting things done, one might think he's right in his anger, as a text editor usually is just about the lowest barrier of entry to a software development problem. HEY GOOD DISCUSSION THOUGH.
I went to a startup pitch event the other day. VC's on the panel were asking the entrepreneurs the usual cadre of tough financial questions. Questions like: "How are you going to spend the time and money once you get funded?".
What do you think would happen if someone said something like this?
"I am going to take a month or two to learn and get really good at vim because I keep reading on HN that it takes too long to reach for the cursor keys. Then I'll start building the product you will be investing money on."
I don't know about that panel. If I was on the panel the lightest kick would land the would-be entrepreneur on the moon without a rocket.
Not important. Not significant. A complete and utter waste of time, focus and mental resources.
Awesome strawman you have there, and the same non-argument could apply to any technology: "I am going to take a month to learn Ruby...". In any case, you can relax - no one is trying to take Notepad away from you.
Ridiculous. Taking a month to learn Ruby is so vastly different than taking a month to learn vim that it defies comparison. One actually has the potential to give you an order of magnitude productivity gain while the other will do so little for you that you might as well call it nothing.
Let's exaggerate in order to enhance the effect.
Both you and I launch new startups to produce exactly the same web software product.
We both get programmers who have zero experience with vim and Ruby. Let's say they only know PHP and only know how to use Notepad++. No frameworks.
I have my programmers go to Ruby class and learn Ruby on Rails for a month.
You have them learn vim for a month. They get to stay with PHP.
Not fair? One is a framework designed to speed time to market while the other is just a text editor? Exactly!
Who do you think will see the greatest productivity gains in a month?
In six months?
Who will ship product first?
Who will ship product with more features?
Who will ship product with less bugs?
Who will go out of business?
Who will get fired by the board?
Right.
Or, let's take a different route:
Our investors just gave us a million dollars each for these startups.
I go to mine and propose that I want to have the entire team take a month to learn RoR due to the productivity and code quality gains we are going to be able to derive by taking this approach.
You go to yours and tell them that you want your team to spend a month learning vim because it takes too long to go from home row to the arrow keys and you can shave seconds while editing.
Sign-up for YC and tell PG that you are going to have your entire team go learn vim for a month instead of something that delivers real productivity gains that are orders of magnitude greater.
Who gets fired?
Again. Right.
When you measure what really matters just about any argument for vim is as hollow as can be.
> Let's exaggerate in order to enhance the effect.
Let's not, they are entirely irrelevant.
Noone is claiming that any specific tool will make your startup succeed, or fix your bugs, or add features to your software for you - I thought we were discussing text editors.
I don't know what you are discussing. I am discussing the absolute fact that focusing on any real or imaginary gains that could be had by insisting on using any editor at all is ridiculous in the context of where the real problems are in developing software products.
> For all that name dropping of the vast and expansive techs you've worked with, you seem to be extremely close minded on this issue.
It's exactly the opposite. All of that has given me perspective that seems lacking on some entering into these religious conversations. I don't even know how many code editors I have used over the years. I probably couldn't list them. I've even had to write some of my own. The point is that across all of those technologies, platforms and years, this has never mattered. The text editor has never --ever-- played a significant role in the factors leading up to the quality, schedule, success or failure of a project.
If you like using vim and messing with it. That's OK. I use it too when I work on Linux. No issues there. Now, to go to the extreme to say that one is not a professional programmer if one does not use vim (I claim I have seen many times) is, well, nonsense.
In addition to that someone chose to call me a fool who does not know what he is talking about. I felt the incomplete list might be a reasonable superficial qualifier. Not enough? My email is in my HN profile. Shoot me a note and I'll provide you with my Linkedin profile.
My primary objection to the "vim religion" is that newbie programmers are almost intimidated into wasting their time with such an utterly insignificant aspect of the job. This is particularly true of someone who wants to be an entrepreneur as opposed to a data entry clerk. There far more important and useful places to spend your learning hours than learning to use a shit editor with a shit UI that originated at a time keyboards had half the keys they have today, GUI's did not exist, monitors were terminals that displayed 80 x 25 characters and mice were nowhere to be found.
In the context of starting, launching, growing, evolving and maintaining a tech business spending any time to get into something like vim is an absolutely irresponsible waste of time and effort.
> In the context of starting, launching, growing, evolving and maintaining a tech business
Possibly, but some people are not starting, launching, growing, or evolving anything but software - and a text editor is where 99% of that work happens.
That's interesting. I would say that somewhere between 50% to 75% of my time when creating a software product is devoted to documenting requirements, analyzing the problem, studying candidate solutions, working out such things as state diagrams with, yes, paper and pencil and, in general, thinking and planning.
I haven't measured it but I'd venture to say that actual time typing code is probably somewhere in the order of 15% to 30% of a project, if that high. In fact, I really doubt that initial code entry goes much past 20% of my time.
Then there's testing, debugging and source control/management. If the project requires media a substantial amount of time might also be devoted to the creation and management of image, video and sound assets.
One interesting thing is that as the years went by and I became more experienced I quickly spent less and less time debugging. My code is largely bug-free due to the fact that I devote a lot of time and effort to initial planning before I even think about firing-up a text editor at all.
So, yes, your claim that 99% of the work in creating a software product happens in the editor is something that can only be true for an absolute rank newbie. I don't know many experienced programmers that, for a non-trivial project, just launch into an editor and spend 99% of their time there.
Its nice for you that you're advanced in your carrier that coding is such a small part of what you do, but its obvious that theres enough people that arent quite as godlike as you. Good for you.
Personally, the one thing vim(and Linux) have taught me is that mastering your tools is hard in the short but entirely worth it in the long run. Do really never learn shortcuts or concepts or the tools you use? A language is just as much a tool as a text editor.
How much of your time did you waste here, religiously debating religious vim users? At least from here(the internet can distort things) it seems you're just as religiously anti as they are pro.
I have started (and self-funded) at more than three technology businesses in my life. I am in the process of starting two more.
Wow, it's sad that parent never learned how to use a real text editor. Can you imagine how much more he could have contributed to the world if only he hadn't been held back by bugs, delays, and quality problems inflicted by bad tools? If only some stubborn people would invest a little time in learning vi or EMACS, the world could have so much more productivity from people like that.
As for myself, I don't really care much about speed while coding, however, I do care much about being efficient at doing things.
Why should I have to move my hands up to reach the arrow keys, if I can use the home row instead? I do think it is very tiresome to move my hands around (maybe because I'm lazy?). This of course applies to the mouse/trackpad as well. Again, you need to move your hand to away.
Again. Not necessarily about speed, more about efficiency and convenience.
Today. Sure. Imagine my surprise when I see yet another bullshit vim article on HN, this one now saying "don't use the hjkl" keys. When will the madness stop?
Newbie programmers reading HN actually need to hear from someone who clearly sees that the emperor has no clothes. Some look at HN as the reference by which they ought to shape their learning and careers. There's a definite pro-vim bend here. And it's all bullshit.
If your goal is to be an entrepreneur, focus on the stuff that actually matters and is many orders of magnitude more signifiant than a ridiculous text editor from an era when keyboards had letters, numbers and three or four extra buttons.
If you want to be a fast data entry operator, definitely spend months getting good at vim.
Better yet, buy one of those single-hand chord-based text entry keypads and modify vim to work with it. You'll be able to type faster and with only one hand. Not sure if the work will have any quality at all or if it will be bug free or if you will be building anything anyone wants or if it will be profitable, but it will be awesome to behold.
Single handed chording is not for speed, it's much quicker to alternate fingers of each hand because you can be moving one into position while pressing another. Chording is also slowed down by having to clearly release all the keys between keypresses, where normal keyboards can have some overlap as long as the sequence is still clear. Also reducing 10 possible inputs down to 5.
If you want to type significantly faster English text, stenography looks like the best approach by a long shot. Not so good for symbols though.
I can assure you Vim is not making a MILLISECOND difference.
Vim is making a 5 seconds difference on every edit. Each edit can be defined as commenting out blocks of code, insert/delete text, or moving blocks of code. If your IDE provides convenient key combo to do these tasks, then great, you have no reason to use Vim. But as soon as you reach for your mouse, you just wasted 1 seconds. Dragging your mouse to select the text you want to change takes another 5 to 10 seconds.
> Oh, yes, and 100% of your time is spent coding. You don't lookup documentation and you don't do any file management at all.
Documentation lookup is much faster through terminal :) Man page is easier to navigate than JavaDoc because of that no mouse needed.
File management is easier and faster through terminal. Think about the process that you move/copy file in GUI. 1) You open one Window, then navigate through folder tree with mouse double clicks; 2) You issue a copy command to the file you want to copy/move; 3) You mouse click to destination folder then paste it. Terminal based file management is just `cp /source/folder/autocompleted/with/tab/key /destination/folder`
I think the true argument here is not Vim or not Vim. It's about mouse or no mouse.
> Vim is making a 5 seconds difference on every edit.
Please. I'm on the floor laughing. Five seconds. I'm not 12 years old any more. I learned to use a stop watch a long time ago. If you want to believe your own folklore that's fine with me.
In any non-trivial software project far more time --ORDERS OF MAGNITUDE MORE TIME-- is spent (or wasted) on planning, executing and, yes, fixing bugs, on software. The speed of your text editor is a rounding error in the balance sheet.
You're a professional programmer, you use a keyboard all day, so you touch type right?
hjkl sits right on the home row, where your fingers sit. It is just a natural place to put movement keys. Nothing to do with the number of keys on the authors keyboard.
Like you say when your jumping around a lot then it matters less. When you're typing a lot then it does matter to keep your fingers on the home row.
> You're a professional programmer, you use a keyboard all day, so you touch type right? hjkl sits right on the home row, where your fingers sit. It is just a natural place to put movement keys. Nothing to do with the number of keys on the authors keyboard.
And my point is that it does not matter. Use the mouse. Use the arrow keys. Use the function keys. Use a GUI. Use multiple monitors.
If we are talking about productivity and code quality, the editor is orders of magnitude less significant than a huge list of other things. It does not matter.
Then we have someone now saying "don't use the hjkl" keys. Really? How far is the idiocy going to go?
If I am building a business or a product the last thing on my mind is what text editor we will be using. It is so ridiculously insignificant in the grand scheme of things that seeing people focus on it is beyond comprehension.
Seriously, I can't stop but think while reading your comments that you have a lot of emotions building up within you.
I see your point in people evangelizing VIM, Emacs, Apple, whatsoever, but... who cares? Let them be. I don't see, why you try so hard to prevent people from being happy and enjoy little things in life. Why does everything have to be insignificant, because something else is so much more significant? I seriously don't get your point there.
Let people love their editor, even if it is insignificant to you. People actually are more productive, when they are happy using a product they like, or could you seriously imagine writing code/surfing the web/do anything with the on-screen keyboard? Even you would get frustrated and would hate your job. It does matter. Maybe not the productivity-wise, but definitely how you, as a person, feel.
Well, it's possible that you are confusing passion with emotion. It really takes a thick skin to go against the grain. The grain on HN is very pro-vim for some reason. And, yes, it blew my top to see an article now proposing to go farther and ignore "hjkl". How insane will this cult get?
If all I achieve is to virtually snap a newbie out of the trance created by HN dogma the result is good. It would be a tragedy to promote these tools for another thirty years.
> ... the editor is orders of magnitude less significant than a huge list of other things. It does not matter.
The first point is true. The second point is false -- it does matter. Saying that X is less important than Y can't be used to argue that X doesn't matter at all.
> If I am building a business or a product the last thing on my mind is what text editor we will be using. It is so ridiculously insignificant in the grand scheme of things that seeing people focus on it is beyond comprehension.
That's true in general, but there's an exception -- if you can improve the efficiency of editing, you might make a basic change in people's thinking and become a millionaire as a side effect.
I think that the value of your editor was not in efficiency --if we define it as "data entry speed". I think it had a lot more to do with a sensible user interface that was accessible and yes, "efficient", for someone --anyone-- to get into. It used that peripherals and accepted UI norms available at the time and it did so well enough to be successful.
vim is a cult based on metrics that are not significant drivers in the context of building a software product or company.
> I think that the value of your editor was not in efficiency --if we define it as "data entry speed".
Oh, I agree -- based on modern standards it was quite primitive and somewhat poky when used by an experienced touch-typist. But I was only comparing it to vi. :)
Imagine if there was a way to edit text entirely through just mentally thinking what you wanted changed? No physical overhead whatsoever, but just having the text change as soon as you mentally think, "change this parameter name to ___" and it happens. Being proficient in a good editor, like vim, makes that slightly closer to reality than using traditional, non-modal editors. Even so, this slight difference can have the major effect of helping the editor "get out of the way" and just let you make the changes a bit more proficiently - essentially freeing your mind up a bit to think about what you are changing instead of how. Physical traveling to the cursor/arrow keys to move one character or row at a time is wasting your time and a bit of mental energy, since you can't quickly and efficiently get to where you want to edit immediately (e.g. your brain has to do more and wait longer in between thinking, "x should instead be y" and it actually being changed).
> this slight difference can have the major effect of helping the editor "get out of the way" and just let you make the changes a bit more proficiently
I have never, in THIRTY years of designing hardware and writing software, been slowed down by a text editor of nearly any kind (other than the first time I used VI). And, yes, I can use vi and vim. And yes, I think it is total horse-shit. The things that have slowed me and others down, caused projects to fail, caused robots to crash and damage something or caused the success or failure of a business have been orders of magnitude removed from any advantage that could be had via a text editor, even if it was wired into my brain.
It is OK to make oneself believe that this is really useful stuff. Some people believe in all kinds of invisible things. And, in that context, anyone going against those beliefs is a lunatic. I am, on more than one front. I prefer to focus on what is real and what is significant.
You are mostly missing my point, which has nothing to do with vim use magically making what you code perfect. Not sure why you are trying to say that is what we are positing. All I said was that it takes some of the mechanics of modifying text out of the way making editing a bit more efficient in that regard (once you become proficient). You can still efficiently code crap, of course. Who is saying otherwise?
There's a religious element in the "cult of vim" that proposes that one is not a professional programmer unless one joins the cult and becomes proficient at vim. This is followed by implications of code quality and capabilities. None of it, of course, is true. I am not and don't think I attributed any of this to you. If I did, I apologize.
Interesting argument, and I agree with you that the milliseconds saved are obviously small compared to the time it takes to design an algorithm, but I will make the following argument:
It isn't only about shaving milliseconds off your coding. I realize this is mostly anecdotal, but I find when I'm editing in vim or any good IDE, I can focus more on the algorithm and less on the act of typing, and a deeper focus on your program (i.e. data structures, control flow, etc) rather than on typing, does have an advantage.
Holding down the left or right arrow key while waiting for the cursor to move to the end of a line, or reaching for the end key is distracting and interrupts concentration, even if it is brief. Waiting for a cursor to move puts a greater strain on working memory because it means maintaining state information, in memory, for a longer period of time. While these distractions are somewhat minor for a single line of code, they really add up when you're' coding for 8 or 10 hours a day. In fact, I find these distractions add up to the point where I need to be editing in Vim or a good IDE to get in a state of flow.
Now, before someone calls me out on it, I'd also suggest that I don't believe using vim or an IDE increases the load on working short term memory. When you're initially starting out with a new tool, obviously it does increase the working load on memory, but once the key bindings are committed to muscle memory then, almost by definition, you're no relying on working memory.
Of course, I do understand what you are saying. Now, also consider that your experience might not be common.
I am no stranger to 16 hour coding marathons. In fact, about 15 years ago I launched a company out of my garage. For the first nine months or so I nearly locked myself in the garage for 16 to 18 hours a day coding. The work required a combination of Verilog for the FPGA, C for the embedded processor and Visual C++ for Windows. Three different editor/IDE's: Xilinx ISE, Keil uVision and MS Visual Studio. Over the nearly nine months of intense 12+ hours of straight solid coding in that environment I could not give you one example of situation where having to reach for the "END" key, the mouse, the arrow keys or "Ctrl-F5" or whatever bothered me in any way imaginable. The IDE's and the text editors, for the most part, were relegated to background noise.
The things that slowed me down, caused grief and broke my short or long term concentration and my ability to maintain state have never, in my thirty years of programming, had anything whatsoever to do with the editor and the keystrokes I might have to use running it.
Anecdotally I will make a blanket statement and say that this is exactly the case for the vast majority of programmers. No, I don't have data other than to say that I have worked with lots of people over my career. Across platforms, languages, tool chains and editors I have never heard anyone complain about loosing state or concentration due to the editor. Until I started reading HN.
Is there a type of personality, a type of programmer that can loose state from something as insignificant to some of us as reaching for the mouse or the arrow keys constantly? Maybe, I don't know. I have yet to meet someone like that in person. If the answer is "yes", I'll have to simply take your word for it. I don't know.
It might be also important to consider for a moment that those who have NOT forced themselves to use vi/vim are perfectly comfortable with the keystrokes and commands typical modern editors use.
If you stick to Windows and even Linux GUI the vast majority of the navigational commands are the same that you might find in MS Word, Excel, Outlook and your web browser. The "Ctrl-C", "Ctrl-V", "Ctrl-X", "Shift-[down arrow]", "Shift-[end]", "[home]", "[end]", "Ctrl-[left arrow]", "Ctrl-F", "Ctrl-H", "Ctrl-S", "F3", "Shift-F3", mouse scrolling modes and other commands are part and parcel of this "muscle memory" a lot of vim proponents mention.
In other words, nobody thinks "oh crap, I have to reach for Ctrl-F again", it just happens. And, it happens with great uniformity across platforms, applications and tools. Various tools introduce a few (or a lot) of specialize commands, like "Ctrl-F5" for "compile and go" on an IDE, "Ctrl-B" to "build" or "F12" to launch your site on a browser on something like Dreamweaver. These are not and have not been problems for anyone with whom I have ever worked.
Here's what I find interesting. I was using real terminals and 300 to 9600 BAUD teletypes over real leased lines talking to mainframes towards the very tail of that era in the 80's. I even had a little bit of experience using Tektronix storage tube terminals (one of the few ways you could render APL characters at the time). All of these had crippled keyboards with half the keys we have today. Editors at the time were weird and had shit user interfaced due to the limitations of the hardware. Every single one was different. Either you had modal editors or editors with weird Ctrl-<something>-<something> keystrokes. When CPM and S100 computers came along you could get WordStar and eight inch floppies. Ctrl-K-X brother! I even owned a real DEC VT-100 terminal.
I think I can safely say that those of us who came up that route were GLAD to get rid of these shitty UI's and crappy contorted-command editors that were a pain in the ass to use and learn. As keyboards and peripherals evolved and we got things like "standard" keyboard with expanded key sets (Thanks, mostly to IBM and the PC revolution) things began to standardize around the newly available keyboards. No programmer in their right mind would write a text editor at the time and IGNORE all those extra keys. The only way you could even consider writing something like vi is if you didn't have any option but to write vi due to hardware limitations.
And so, what I find very interesting is that here we are, so many years later with better hardware, software, multi-monitor GUI's and computers with gigabytes of memory and direct DVI connections to the monitors and we have a class of programmers that insists that --to be effective and to be considered a professional programmer-- you have to use a tool who's only reason for being designed as it was thirty years ago is that the writer had a keyboard with half the keys, over a 300 BAUD modem, a crippled terminal, limited memory, no graphics, 80 x 25 characters and no screen buffers. Please understand how someone like me could see this as being nothing less than ridiculous. Even vi's author relates the story of having gone down the path of adding windows to vi but loosing the code in a crash and never going back to re-creating it (the implication being that vi was already on a path to become a totally different product).
Anyhow, at some level, of course, to each his/her own. My problem is with vim zealots who in places like HN tend to give newbies the idea that there are magical qualities attached to adopting the "cult of vim". From my perspective nothing could be farther from the truth. And, as I have stated, from a business perspective, there are far more important and significant levers and knobs in a business to focus on than which editor you are using.
hahahahahah. I use vim. It probably takes me a good deal longer to get anything done in it. I do it cuz I like the challenge. And I am not particularly pressed for time. Also it's just faster when do you know what the eff you're doing ;)
I was hoping someone would trash the idea of hjkl, which I personally don't like. So first I was disappointed to read yet again about not using the arrows.
Then when I read the rest of the post, it definitely makes sense. I do use w, b quite frequently, and I don't use f, but I've found the vim-seek[1] plugin recently, and it seems to make more sense to use. It matches two rather than one character, which makes it much more precise.
I think the bottom line is to move around to the right place and that going one character at a time is less efficient. Not so much whether this movement is via hjkl or the arrow keys.
I'm now considering extending the seek idea to moving to close-by lines, through mappings that would work like EasyMotion's w, b, e and ge but excluding the current line and working on lines above (b and ge) and below (w and e), by typing the two characters that respectively end and begin the target word.
sounds cool. One thing I couldn't work out with the plugin, was how to skip to the next match. It's rare that two letters match, but some letter combinations are still relatively frequent, things like `if` or `th` ... but perhaps it's just a RTFM issue and I haven't used it extensively yet...
What I like about VIM people is they explain you that mouse is evil, arrow keys are evil and now the basic hjkl (btw corrected into hell in iPhone keyboard) are evil too.
I have even see a guy at a ruby conf who were using only keystrokes to browse the web. I wonder how it deal with flash animation. Anyway so now, he can replace his trackpad with a swimming pool for worms of smugueness. That's pretty cool.
Most of the comments in this thread can be summed up with:
1. "Vim sucks/is better than _____ because...."
2. "Finally, somebody's preaching the truth! Who even uses the HJKL keys? Not me..."
3. "I think I will/won't consider adding 'w', 'b', 'f', etc. to my Vim inventory because..."
1. This is not a productive comment, and this thread isn't here for you to start an argument on something rooted in personal taste. Your're entitled to your view, but this post was written as a suggestion for Vim users, for Vim users. Please, refrain from posting if that's all you have to say.
2. That's great that you've found more efficient ways to navigate, but did you read the article? Though it's impossible to tell from the extremely-misleading post title, the article isn't polemicizing - it's trying to suggest tools that a user might not already know/be familiar with.
3. These comments are the only ones discussing the actual article text, and are the minority. Let's discuss the merits of what the post was actually talking about, as the comments are meant to do!
I have in my vimrc something I'm calling restrain.vim. In effect it allows me to rebind a double press such as jj, kk, hh and ll to do something else. That means I can only press any of these keys once, if I press a second time it does a different thing (I'm using j and k for jumping to the next line number ending in 0, or ending with a digit if I supply a count, so it's kinda like relative line movement with absolute line numbering).
So when I press j once it moves down one line, and if I press any other command it's reset so I can press j once again next time (so it allows going down a line and pressing . repeatedly). But from the second consecutive press each single j press will be doing another thing. This is helping me a lot with retraining to using other methods to get around instead of spamming j. Wait, that's a good wordplay, restraining, retraining. Hmm..
Hard mode, that's great. Does vim have a help-a-fellow-learn-vim mode? Instead of it's normal Mostly-fail-to-give-you-any-visual-feedback-and-just-treat-you-with-smug-indifference-while-you-try-various-keys mode?
I could swear if you just ran the command "vi" rather than opening a file with vim it would load to a screen that shows you how to run the tutorial. I can't confirm that since I'm on a Windows machine at work right now, so I won't argue it. It does exist, but I'll acknowledge that it's not advertised heavily.
I just freshly installed vi and tried that. Here's what I was greeted with. http://pastebin.com/HxvNP6Tr I've seen the tutorial that you're probably talking about a few years ago when I got curious about vi. It didn't really do it for me at the time.
I'm prepared to believe that people willing to tolerate its ideosyncracies can be very productive in vi or vim. I've seen it first-hand. It also appears to be well suited to potentially reducing rsi-type problems. But it is not intuitive to learn nor is it the least bit friendly. That's a shame too because there is no good reason why it couldn't be so.
No advice on moving from line to line? Word and character movements are great (and well worth learning), but how do you suggest moving to just the next line without spamming `w`?
If you want to go to the same cursor position on the next line, definitely j is the way to go.
Much of the time, I want to go to a specific part of the next line. In which case, let's say I want to go to the parse function, I'll do "/par<enter>".
I don't see those as an improvement (i.e. worth committing to muscle memory) for `j` and `k` that would incentivize me to no-op those two keys. You can do `4j` as well.
This is excellent advice. I've met so many people who thought HJKL was the only way to move around in Vim. Moving around with other keys really boosts your productivity.
If I can see where I want the cursor to be, why can't I put the cursor there ... by looking at it and pressing a 'jump to' modifier, or by touching it, or whatever.
Even as a Vim fan, this isn't better than mousing, this is similarly annoying to proxy movement through other things.
I don't even use vi(m) anymore, but hjkl are so burned into my brain that one of the first things I had to do to http://inky.com was make hjkl work to move around in the message list.
I see too many love-hate comments in here, I realize now that people can be really fanatical about their preferences for editors.
For what is worth, I use vim and visual studio in daily basis, and love both. I love vim experience over a console and the fact that I can code in a remote machine without any perceptive latency.
I love visual studio goodies (mostly intellisense) and being a keyword guy I just learnt VS shortcuts.
So, Is there something wrong with me? for me those are just tools not religions.
Edit/PS: I know am comparing an IDE and a editor, but in this case I think the analogy is valid
I hate hjkl for the simple reason that I learned to type with my index fingers on F and J keys. I use search a heck of a lot more but I guess I should add w, b and e to my repertoire.
I also learned to type with my index fingers on F and J (I think it's quite standard, given the typing classes I took and the little nibs on my keyboard), and I've always been fine with HJKL. What's the problem you have with it, exactly? It sounds like you're saying you'd prefer jkl;, but I don't think that would be better; moving to the left seems perhaps least common to me.
Is there a way of typing which does not involve having one's index fingers on the F and J keys? I thought that home row position was standard (regardless of keyboard layout - I type dvorak but my index fingers still rest on the keys marked F and J).
Using <leader><leader>f <char> will display all available options to jump to. This way you don't have to continue to use f<char> over and over if there are many of the same character in the line you are on. It is also a great way to jump to a very specific spot in your code.
Note, it also has other motions besides just f. Here is the link:
I use control keys for a lot of my movement. <c-f>/<c-b>, <c-u>/<c-d>, <c-e>/<c-y>, <c-n>/<c-p> (remap your ctrlp plugin to leader p. This is vim.) And yeah, I have caps lock remapped to control. Setting virtualedit=all will also force you to think in terms of text objects by allowing the cursor to move everywhere. No longer can you simply press j/k and have it go to the end of the next shorter line.
I've never felt too pressed to learn vim, but I now realize how nice it is to be able to open the same exact editor with the same exact shortcuts on any linux machine in the world. I have 20+ servers I need to SSH into on a weekly basis, and I would much rather benefit from the convenience of using vim on every one of them than some hacky SFTP solution with Sublime on my machine.
I never found the keymap cheat sheets useful. It tells me what happens if I press a certain key, but what I need is the reverse. Tell we what key to press if I want X to happen.
When using a cheat sheet like that I waste a lot of time scouring the image looking for text relating to the type of operation I want. I'd rather have a list of options grouped by operation type.
I have a deck of flashcards in Anki to help learn vim bindings in a way similar to what you're looking for.
The flashcards are designed so the front is a description of some operation (ex. "motion cursor to end of the line" or "backward find word under cursor") and the back is the key combo to make that operation happen.
It is organized by types of cheats. It's more of a tutorial that aims to familiarize you with available features comprehensively. Once you kind of get an idea of what options are available, lookup is a little easier.
This is definitely not the best cheatsheet for hanging above your computer, but more to be read as a tutorial. (Calling it a cheatsheet would be a stretch in this case.)
For your purposes (and what I do quite a bit anyway), google is the best cheatsheet.
He gives examples of how to do away with h and k except for one off errors which is how I work but he doesn't really show a smart way of going up or down 2 or 3 lines without using j and k. I vertically move by using MHL and jk, is there a smarter way than that?
To prevent overusing hjkl a plugin that throttled how many times you could hit the keys in a row would be ideal. That way they would still work for one off errors.
However, after using vim for a long time, I still use the arrows! Not all the time, but a lot. I find that my fingers are always darting around on the margins using $ an ^ and ~ and ... my argument is what's wrong with traveling a little to get to those equally distant arrow keys? I don't really consider the hjkl to be my home position for my hands much. Thumb on space bar is home, if I had to define it.
No, it isn't, and that's the major underlying theme of Drew's writings on vim. This article is no exception. By learning to use the power of the tool, you work fluidly with the structure of the text, not just the characters/lines. That is, your expertise of the tool is shaped to match the mental patterns around the code you work with.
>I’m not really suggesting that you permanently disable the h, j, k, and l keys. ... But...If it forces you out of your comfort zone and encourages you to use wordwise motions, character searches, and other motions, then it counts as a useful exercise.
What vim user does all their movement with hjkl only anyway? If you're going to deliberately cripple your editing habits like that, or if you're not even bother to learn other movement command at the same time as getting used to hjkl, you might as well stick to notepad.exe.