Live data from Hacker News

Vim clutch

github.com

211–220 of 227 posts

Re: Vim clutch

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

You have to learn h,j,k,l are not just navigational keys but also can be combined with multipliers like 20h(Moves 20 positions to the left). You know, I've understood this for a while, but to this day I still don't use it. I can't count characters that fast! If you're going to lean forward and count out chars, you might as well count them out with presses of 'h'.

Right, I use w and b to go forward and back one or two words at a time. For lines, I :set relativenumber and use that as a cheat sheet if I want to move or delete n lines down.

Re: Vim clutch

#212

Earlier quoted context omitted.

Note: this post assumes Vim, not other implementations of VI If you type fast, you don't want to have to spend time correcting for line estimations that are slightly off as a result of thinks like 20h. For navigation, just use forward slash to search and you'll land right where you want. It's also almost always faster to use f/F/t/T in conjunction with semicolon or comma for jumping to specific letters than using h o…

In emacs, we do the same with C-s (search-forward) and C-r (search-backward). It is highly recommended to "jump" to the exact text you want, rather than fiddling around guessing and correcting numerical character and line jumps. Just a bit of support from the dark side !

Oh, the search feature! In Vim we call that '/'.

Re: Vim clutch

#213
post #205

Earlier quoted context omitted.

Not really going to help you for 20h...

Difficult to disagree. However if you use 20h, you're probably doing it wrong and should use w/e/f instead.

Usually, yes. The two places I find myself using a count on h or l are 1) in nonce key bindings, and 2) when there's a lot of instances of what I want to jump to near the start of a long word, followed by a gap without the character, followed by where I want to jump. If I'm faced with www.wikipedia.com/something/wouldyouchangethis it's simple to say 10lfwcw - if I'm off by 5 in either direction it doesn't matter and ballparking like that is easy.

Re: Vim clutch

#214
post #199

Earlier quoted context omitted.

CapsLock to Escape is something I find useful with Vim. A lot of people advocate mapping it to Ctrl then using Ctrl-c or Ctrl-], but It's better to just skip the middleman I think.

If you're using X, then xcape can map both Esc and Ctrl to Capslock. https://github.com/alols/xcape

Now that is clever. Thanks for this.

Re: Vim clutch

#215

Earlier quoted context omitted.

VIM clutch does not seem to prevent mode errors, though. For that pedals need to have feedback. I.e., if one hits 'a' out of habit or accidentally, stepping consequently on the insert pedal would predictably enter 'i' character. That would be avoided if the pedal changed to pressed state depending on mode. That said, for me as a pianist the idea of mode pedal looks pretty awesome. It just needs to be developed a bit…

Just need to make sure pedal down is idempotent. Having the pedal send something like Shift+F2 and then `nmap i` `imap ` takes care of that. Escape is always idempotent so no issues there.

If you are appending to the end of the line i will move you left one character.

Re: Vim clutch

#216
post #124

Earlier quoted context omitted.

With no justification of how you think a military helicopter cockpit is user friendly, I suspect you're just trolling now.

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…

If you do state machine code still, check out ragel: http://www.complang.org/ragel/ it's awesome. Since it compiles the state-machine for you, it is much more maintainable than ad-hoc approaches, and as an added bonus will generate state-graphs for you. I used to do the ad-hoc approach to (with an ugly-ass awk script) but since I found ragel, never again!

Re: Vim clutch

#217

Earlier quoted context omitted.

That is simply not true. Not one person has offered any data to support the assertions on vi efficiency. Not one. All I have gotten are the equivalent of "because we say so". I am not flaming, I am not caving-in to the bullying, which is a different matter entirely. In the interest of being constructive I decided to clear the bad blood and start another thread that is designed to educate us who might not understand w…

I suspect there never will be data, because there's too many variables (including developer skill levels), that measuring 'efficiency' of an editor is a pointless exercise. I use vim sometimes locally, but almost exclusively remotely, because the context I'm in at the time precludes using 'real text editors' - GUI apps that get installed and have menus and such. If I have to deal with files on a remote box (example:…

I am in complete agreement with everything you said.

I too have had to administer and support remote systems where vi was the only viable way to edit config files and the like. And, much like you, if I could, I would go for bringing the files into my local system for editing with a non-vi editor (a secondary reason being that if I screwed something up by accident I wouldn't take down a system).

In over twenty years of programming my intersection with being forced to use vi was never frequent enough to warrant spending the time to get good at it. None of my work suffered for it, of course. In my current business nobody uses vi and we get quality work out the door like anyone else. And, I should say, without the need for foot-switches :) --had to throw that in for a little dose of levity.

Thanks.

Re: Vim clutch

#218
post #184
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…

There are two other advantages to using hjkl, that hardly anyone ever mentions:

1. Ctrl-H is Backspace, one of the most used keys, and much more conveniently placed than, er, Backspace. It's right next to the index finger. It's intuitive (in vim) because H is "go left". Ctrl-H works everywhere, in the shell, in OS/X all over the place, it even works in the Windows shell. It's some sort of fundamental mapping to Backspace such that can't actually be re-mapped.

2. Ctrl-M is Enter, another one of the most used keys, and also more conveniently placed than Enter. As with Ctrl-H, it fits under index finger, it's an ancient mapping, underrated, works in lots of places, even in Windows shell.

If you use the crappy arrow keys, your fingers are totally in the wrong place!

Re: Vim clutch

#219

Earlier quoted context omitted.

Editing efficiency, which is what everyone else here is talking about, is (I suspect), completely unrelated to business efficiency (which seems to be what you are primarily talking about). Your Bill Joy quote is talking about editing efficiency. I do not suggest that editing efficiency has a measurable impact on business efficiency, and I do not see anyone here suggesting that it does. You seem to be under the impres…

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.

Re: Vim clutch

#220
post #184
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…

These days, almost all potential vim users have been using the sensibly-arranged arrowkeys for years before they start using vim. Vim puts a second set of arrowkeys right under their fingers, but it has a different, awkward arrangement that makes no sense on a modern keyboard and conflicts with vim's mapping of the real arrowkeys. In vim, the middle finger sits on the DOWN key and reaches up to go up if you are on the arrowkeys (as everyone assumes), but if you are on the home row, your middle finger now means UP instead of DOWN and to get DOWN you go LEFT.

Yet you "don't get" why that might be a problem for people? Really? If it is what you claim, "the single biggest roadblock," then there is something important here, whether you get it or not.

You argue that if you rely on these awkward arrowkeys, "you're doing it wrong anyway." Does that mean they don't really matter? If not, then the using the most prime of the keyboard real estate for operations that "real programmers" don't have much use for would be an even worse design than I'm claiming. If they are important enough to dominate your right hand home row, and I think they are, then your argument is meaningless and they ought to be rearranged so that this no longer "the single biggest roadblock."

And this second reason is silly. Training your finger to reflexively move left instead of up to insert text to the left is going to be a challenge of the same magnitude as relearning arrowkey movement? You think so? People who have been using "copy" for years have to learn that copy in vim is called "yank" and the t,T commands mean, well, "till", and you have all sorts of ctrl-* and meta-* commands to somehow learn, but having to learn to use h instead of i would be such a hurdle that it's really a show stopper for fixing the arrowkeys? That's really your second strongest argument?

These aren't real arguments. Long-time vim users argue that one of the glories of vim is its marvelous customization, but if you customize the basic movement keys, it's supposedly a horror because, well, you then won't be able to use a non-customized vim. So, what's the customization for? It's for secondary things, not something so fundamental. Then you're told by someone else that, besides, if you are using the movement keys much, you're not using vim correctly. Which sounds like a claim that the movement keys just aren't fundamental. And if they're not, what's the problem with customizing them.... What a bunch of nonsense.

It's all a smokescreen for maintaining backward compatibility with a poor design that has spread, mostly in the heads of old programmers (the ultimate "legacy systems"), but also into some software. But for those willing to admit that backward compatibility is the only real argument, think of how much MORE legacy there is these days for the real arrowkeys in the minds of non-vim users and in software of all sorts.

I think vim should change its defaults. It probably would if it were a commercial product, but that won't happen, because defaults in vi/vim are by and for long-time users, not potential users. But it is, as claimed, customizable, and so are most systems (like zsh) that have a significant vi-mode. Systems that don't have a serious vi mode but just toss in a couple of shortcut keys, like j&k, can be learned ad hoc, the way we have to learn all the other shortcut keys that have different meanings in every program.

So, I'm customizing vim & zsh, using the real (physical) arrowkeys occasionally if connecting to a plain-vanilla vim/bash, and it's working out just fine.

Post reply on HN