Vim users: stop using hjkl
vimcasts.org
vimcasts.org
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.
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.
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.
Move the window with the scrollbar (faster than anything else, actually), then shift click at the end of the desired selection.
Bam! Just as fast if not faster.
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.
This is the best argument yet in favor of vi/vim -- it keeps you from doing things quickly that you would later regret.
> ... the obsession over mashing keys as fast as you can seems like a bad smell in terms of developer attitude.
Unfortunately, that's not an argument in favor of increasing the number of pointless keystrokes.
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:
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.
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.
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.
edit: wording
edit: wording/lower verbosity
edit: typo
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...]
Much easier to use and learn than Vim. Just as fast.
SublimeText also has vim keybindings that I never bothered to use, and never will.
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.
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.
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.
So, if someone people enjoy vim, celebrate them. Same goes for whatever you use.
I do agree that the assumption that nothing can exist beyond how one sees things possibly ever being right being the realer and bigger problem.
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.
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.
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.
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.
The article isn't about not using h,j,k,l completely but encouraging people to use those other keys for movement.
(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.)
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".
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.
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. :)
The above refers to my free world sail book: http://arachnoid.com/sailbook
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.
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.
Otherwise - in a slightly less nice way than last time - get lost.
If that's your argument in favor of vi/vim, then other vi/vim users may ask you not to be on their side.
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:
http://stackoverflow.com/questions/1379198/in-vim-how-do-i-d...
Notice that no one says "have you considered solving the problem by changing editors?"
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.
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.
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.
SublimeText2: Ctrl-Delete: deletes the rest of the current word.
To fix my blunder:
Delete rest of the current word (and go to insert mode when applicable)
Vim: ce -> ST2: Ctrl+Delete
Delete current word (and go to insert mode when applicable)
Vim: caw -> ST2: Ctrl+D, Delete
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.
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.
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.
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 didn't say Pico was easy to use. I said it was easier to use than vi/vim.
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.
And when talking about IDEs and code writing remember to include VIM plugins in comparison.
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!
> 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.
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.
Source: http://www.lagmonster.org/docs/vi2.html#delete
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
> This comment is ridiculous.
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, 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.
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.
(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.)
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 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).
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.
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.
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.
"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.
Grow up!
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 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.
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.
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."
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.
You may even find (god forbid) that you enjoy it.
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 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.
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 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.
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.
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.
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.
Don't take my word for it:
http://www.codinghorror.com/blog/2006/09/when-understanding-...
http://programmers.stackexchange.com/questions/93302/spendin...
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.
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.
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.
/ off topic.
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.
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.
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.
Guess how I know this.
vim is a cult based on metrics that are not significant drivers in the context of building a software product or company.
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. :)
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.
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.
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.
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.
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.
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.
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.
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 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.
Try pentadactyl for a couple days. Once you get used to it you will not want to go back to being a mouse-pointer sharpshooter.
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!
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..
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.
:nnoremap k gk
:nnoremap j gj
These move up/down one character, even if it is the same line wrapped over. Really beneficial for things like LaTeX editing.
and - to move 1 line up. Combine with a number, 4+ to move down 4 lines, complementing 4G or :4<CR> to move to 4th line.
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>".
Even as a Vim fan, this isn't better than mousing, this is similarly annoying to proxy movement through other things.
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
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:
The pdf version can be found here: http://www.glump.net/howto/vim_graphical_cheat_sheet
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.
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.
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 works really well for me and I've noticed a huge improvement to my productivity in vim. If you're interested: https://github.com/MrPants888/vim_flashcards
Using those keys once or twice is, of course, perfectly fine. One could set up some mechanism that limits the number of repetitions in a row.
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.
If I have to pay that fraction of time for the convenient arrangement of keys. I will pay it happily.