Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vim clutch

github.com

Post reply on HN
Print view View original

221–227 of 227 posts

Re: Vim clutch

#221

Post by jodrellblank »

kamaal wrote: post #65

I don't know how this would work out ergonomically. My dad is a cab driver and he often complains that pressing the clutch with his foot often giving him RSI kind of pain. But however I think this is purely subjective. From an experiment perspective, this is really cool! And this generally qualifies into what could one call a 'real hack'. This has a air of freshness to it. Now the real power of vim is in getting into…

http://web.archive.org/web/20090323065900/http://vi-improved... (no longer exists on the site) is where I picked up the vim model.

It looks a bit untidy, but it's a very quick read because it's a low-density chat log.

Re: Vim clutch

#222

Post by robomartin »

pka wrote: post #219
robomartin wrote: post #187

Earlier quoted context omitted.

Unless your programming is a hobby, then it IS business. It sure is to the guy paying the bills. Imagine a conversation like this: PROGRAMER: "Hey, boss, on Monday we want to switch to vi/m because everyone says it is more efficient". MGR: "Do you have any data to support that? Will the project get done on-time, on-budget, faster, better and with less bugs?" PROGRAMMER: "Well, I can't guarantee any of that and can't…

Managers like you are the reason why I quit my day job and started a thing on my own. Best decision I ever made.

And yet, the only thing you know about me is that I am not willing to grind my team of over ten programmers to a halt just to have them learn a tool (any tool, not just vi) that offers no quantifiable code quality or project-level productivity enhancements at all. By some accounts on other threads, mastering vim isn't a one-week stint, it could take weeks.

If you are saying that, in your own business you make decisions that would bring your entire team to almost an absolute without solid business or product quality justification. Well, more power to you. Live long and prosper.

Re: Vim clutch

#223

Post by kgen »

graywh wrote: post #131
kgen wrote: post #101

I wonder if this would work better as a temporary mode (like how a real clutch works). For example, you stay in insert mode until you press the pedal, which escapes you to command mode, and then restoring insert mode after you depress the pedal?

How about this? tap for , hold for

Exactly! I would use that way more than the ,, that I use now to break into command mode.

Re: Vim clutch

#224

Post by qu4z-2 »

robomartin wrote: post #149
robomartin wrote: post #140

Earlier quoted context omitted.

Your first personal attack was subtle: "I understand that you like to click through your menus" Now you resort to calling me a troll? That's nice. There's nothing unfriendly about a helicopter cockpit. Even if you've only played with flight simulators anyone half-way intelligent can probably figure out most of it within a few minutes. Flying one is a different deal, as mastering and understanding the complex relation…

As a follow-up to that. When I hire programmers I only care about how well they can reduce a problem to a viable game-plan and how clean and well-documented their code might be. I could not give a crap about whether or not they are 3% more efficient at pounding out keystrokes on a text editor. We waste far more time in other areas than in the mechanics of editing code. In other words, if editor efficiency is adequate…

For the record, it's not that text editing 200% faster or whatever will make a significant difference in productivity. For me it's about removing one more impediment that gets me out of the state of flow. And I am more productive in that state. Some people use the Eclipse or Visual Studio shortcuts. I've learned the vim ones, because they're available on more platforms :)

As a side note, the foot pedals are a hilarious idea, but they will in no way improve productivity in vim. Just mentioning it because of your "my editor doesn't need a foot pedal" comments.

Re: Vim clutch

#225

Post by vindice »

aidos wrote: post #54

Interesting idea, I wonder about using it for the Ctrl key instead. I switched to vim some time ago and that's the bit I find most clumsy, especially given the placement on a Mac. I've remapped caps lock to Ctrl, which helps.

I suggest remapping your (utterly pointless) CAPS LOCK key to CONTROL.

You said you were on a mac so:

System Preferences -> Keyboard -> Modifier Keys

Re: Vim clutch

#226

Post by aangjie »

tsm wrote: post #184
SiVal wrote: post #141

Earlier quoted context omitted.

For what it's worth, I remapped vim's navigation keys from the awkward hjkl to the normal inverted-T arrangement i,j,k,l. Then I remapped the inserts, i & I, to h & H. With that, my natural finger movement on the arrowkeys and on the vim home row match each other. The reason vim's navigation keys (hjkl) today are arranged the way they are, left-means-down and right-means-up instead of up-means-up and down-means-down,…

People always treat hjkl as the single biggest roadblock to vi(m) adoption, and I don't get it. Two points: * First and foremost: If you rely on hjkl, you are doing it wrong anyway . You should be using f, w, ), :n (for integer n), ^d, ^f, etc. My biggest hjkl use case is using j to idly scroll through a file (or less/more/man page), in which case it's conveniently under my index finger and I love it. I also use l fo…

Am on Dvorak and the hjkl doesn't make any sense at all to the dvorak layout. So i have remapped them to snhd instead, but still i end up moving my hand to the arrow keys. But i now think i should try the up down left right layout. i.e Use c instead of 't' that would help eliminate the flow breaker of moving my hand to arrow keys.
Post reply on HN