Live data from Hacker News

Vim users: stop using hjkl

vimcasts.org

191–200 of 218 posts

Re: Vim users: stop using hjkl

#191
post #119

Earlier quoted context omitted.

> `:w` is as natural to me as ctrl-s. 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 sh…

> And it is two keystrokes instead of one. 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 mo…

> 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.

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.

Re: Vim users: stop using hjkl

#192
post #123
post #88

Earlier quoted context omitted.

> 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, throw…

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 disagree that Pico is easy to use.

I didn't say Pico was easy to use. I said it was easier to use than vi/vim.

Re: Vim users: stop using hjkl

#193

Earlier quoted context omitted.

Must be a fun exercise using hjkl on dvorak. I think I would end up remapping the whole normal mode to the same positions of a qwerty keyboard.

I used vim with colemak for a while. 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'…

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.

Re: Vim users: stop using hjkl

#194

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?…

[deleted]

Re: Vim users: stop using hjkl

#195
post #192
post #123

Earlier quoted context omitted.

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 disagree that Pico is easy to use. I didn't say Pico was easy to use. I said it was easier to use than vi/vim.

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.

Re: Vim users: stop using hjkl

#196

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?…

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.

Re: Vim users: stop using hjkl

#197
post #196

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?…

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 yo…

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-- 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.

Re: Vim users: stop using hjkl

#198

Earlier quoted context omitted.

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 produc…

> 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.

Re: Vim users: stop using hjkl

#199

Earlier quoted context omitted.

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 produc…

> 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.

Re: Vim users: stop using hjkl

#200

Earlier quoted context omitted.

> 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…

> 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.

Don't take my word for it:

http://www.codinghorror.com/blog/2006/09/when-understanding-...

http://programmers.stackexchange.com/questions/93302/spendin...

Post reply on HN