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

A Good Vimrc

dougblack.io

Post reply on HN
Print view View original

91–100 of 178 posts

Re: A Good Vimrc

#91

Post by chris_wot »

dougblack wrote: post #77
Nyubis wrote: post #49

Rebinding jk to escape because escape is too far away seemed like a fairly ugly hack to me, especially because you can't type it anymore without waiting. Why not simply rebind caps lock to escape? Caps lock is used awfully little, considering how prominent its position on the keyboard is. On Linux, you can rebind it by adding setxkbmap -option caps:escape to your .profile. If instead of an additional escape you prefe…

Hi! Author here. Fair points. I'm gonna start out on the defensive: I didn't post the article, which kinda stinks because if I knew it was going to get such attention I would have updated it to my current setup. Anyways as the 1.5 year old article states: This article will almost certainly fall out of date with my vimrc in the very near future I don't do jk escape anymore. I have since abandoned custom escapes becaus…

I once told my wife an amusing story I'd read in Australian Personal Computer where a computer technician was told by a secretary that she was great with computers, said technician was very happy and joked that he was glad as the last person he had to help thought that the way to input capital letters was to press the caps lock key, the capital letter and then press the caps lock key again... To which the secretary asked "what's so funny about that?"

Anyway, I chortled after telling this to my wife, to which she looked at me with a puzzled look and asked me what the punchline was...

Re: A Good Vimrc

#92

Post by scrollaway »

coldtea wrote: post #84
cma wrote: post #70

Earlier quoted context omitted.

It isn't just writing code faster, but also navigating (thus comprehending) faster, and in some cases writing code with less errors.

Has this "faster" thing been measured and profiled scientifically in some kind of A/B testing? Or it's just based on subjective feelings and cargo cult?

https://ux.stackexchange.com/questions/30682/are-there-any-r...

With that said, this is in the realm of common sense for anyone who's ever used vim bindings at least semi-seriously. We're not just talking millisecond improvements, we're talking about doing some tasks that can take several minutes in mere seconds.

Re: A Good Vimrc

#93

Post by chris_wot »

bandrami wrote: post #47
0942v8653 wrote: post #33

Earlier quoted context omitted.

Apple reverses scrolling by default . I don't know about other coders' computers, but there are people who don't know how to change it, and whenever I boot into recovery mode it gets reversed.

It's only "reversed" if you consider the other direction "normal". Either one makes sense: Mac acts like your finger is moving the page itself; X11 and Windows act like your finger is moving the location indicator on the scrollbar. Either one makes sense a priori , but once you're used to one the other becomes intolerable.

Try using it Down Under...

Re: A Good Vimrc

#94

Post by zipperhead »

fernandotakai wrote: post #76
ajross wrote: post #58

Earlier quoted context omitted.

Ack, no. Bind caps lock to Ctrl, and escape is now the trivial chord C-[. As an added benefit, getting used to this layout will help you out with migrating out of vim to emacs.

yup. i find binding ctrl caps way more useful than binding ctrl to esc (and my keyboard even has a ctrl key made for the caps place and a caps key made for the ctrl position). BUT there's also a way to do something like: if you press and hold caps, it acts like control. but if you press and release quickly it acts like esc. stevelosh describes how to do that on osx here http://stevelosh.com/blog/2012/10/a-modern-spac…

See link to xcape in this thread.

Re: A Good Vimrc

#95

Post by ciupicri »

hoorayimhelping wrote: post #14

I don't use vim as my go to editor so I may be asking a silly question; does it just use idiotic defaults or something? I've only met a couple 'vim users' who could just hop onto someone else's vim setup and be productive, and I've never met a single vim user who could use someone else's setup without making comments about everything being different. I guess the question is do people modify vim cause they can or caus…

The default settings on Windows and Red Hat based systems are pretty good. On the other hand, I was very disappointed ~8 years ago when I touched an Ubuntu system. It was too plain for me.

Re: A Good Vimrc

#96

Post by Dobbs »

dougblack wrote: post #77
Nyubis wrote: post #49

Rebinding jk to escape because escape is too far away seemed like a fairly ugly hack to me, especially because you can't type it anymore without waiting. Why not simply rebind caps lock to escape? Caps lock is used awfully little, considering how prominent its position on the keyboard is. On Linux, you can rebind it by adding setxkbmap -option caps:escape to your .profile. If instead of an additional escape you prefe…

Hi! Author here. Fair points. I'm gonna start out on the defensive: I didn't post the article, which kinda stinks because if I knew it was going to get such attention I would have updated it to my current setup. Anyways as the 1.5 year old article states: This article will almost certainly fall out of date with my vimrc in the very near future I don't do jk escape anymore. I have since abandoned custom escapes becaus…

ctrl+] will act as escape in any vim out there. At least that I've encountered.

Having caps as ctrl makes it really easy to hit.

Re: A Good Vimrc

#97

Post by zo7 »

tinco wrote: post #39
zo7 wrote: post #31

Earlier quoted context omitted.

Why would either tabs or spaces be better than the other? Isn't that one of those pedantic style debates that often come down to a matter of personal preference? I'd get rather annoyed if someone on my team was constantly changing the indentation from tabs to spaces or vice versa every time they opened a file. To elaborate on the author's reasoning for using spaces, people sometimes mix spaces with tabs in the indent…

You're mixing up arguments. No one on your team should be changing indentations. You should decide as a team what your settings are going to be, that's why I suggest using DetectIndent to make sure your settings match whatever the project guidelines are. It's not a matter of personal preference though. Tabs are simply superior for encoding indentation. If you use tabs for indentation you can configure their width in…

Oh sorry! I completely misunderstood what DetectIndent was doing, that's a good tip.

I did want to point out that there's some sense to forcing the code to look the same on every machine though. Of course converting tabs/spaces is automatic, but my point was that the mix of the two requires either manual editing or conforming to the width of whoever made the error. It does happen, and I've been on at least one project with a professor who would occasionally mix things up while in the throes of editing (and they used a tab width of 8 which made it especially irritating for others!). With spaces you at least force whitespace to mean only one thing and if you absolutely can't stand someone's indentation width you can still change it like you can with tabs.

This really is personal preference though. Spaces explicitly represent the author's original intention including their indentation width, while tabs make it more convenient to others while conflating whitespace to mean two different things. Both are entirely reasonable though.

Re: A Good Vimrc

#98

Post by charlieegan3 »

code_sterling wrote: post #74
eru wrote: post #63

Earlier quoted context omitted.

> I found the disabling the arrow keys in normal mode was the point of no return! Is there any reason to do this when you have a keyboard that has easily reachable arrow keys? (Kinesis Advantage, in my case.)

Yea, it forces you to use the vim bindings. This is advantageous, since your hands don't leave the home row. It seems minor, but when you actually "get" vim, you'll actually see speed improvements. It sounds silly, the half second saved here and there, but once you've done it long enough, you get into a flow that you just can't get moving your hands to the arrows or mouse.

^ this. I could likely reuse them for something now but when your muscle memory has you going there all the time at the start it's better if they just do nothing. I think it is at least.

Re: A Good Vimrc

#99

Post by to3m »

coldtea wrote: post #84
cma wrote: post #70

Earlier quoted context omitted.

It isn't just writing code faster, but also navigating (thus comprehending) faster, and in some cases writing code with less errors.

Has this "faster" thing been measured and profiled scientifically in some kind of A/B testing? Or it's just based on subjective feelings and cargo cult?

In my tests it's always made quite a difference if your fingers are already on the keyboard, and you want to invoke some specific, non-interactive function; you can usually hit the shortcut, whatever it is, in less than the time it takes to move to the mouse alone.

Few would argue that moving from keyboard to mouse and back between every keypress would be more efficient than just typing one key after the other, as is more usual. The same applies, when activating a shortcut: for example, starting with my hands on the home row, I can do 10 activations of copy (Cmd+C), returning my hands to the home row between each activation, in about 8 seconds. Using the mouse in a similar manner to select the corresponding menu item takes about 22 seconds. Just moving my hand from the home row to the mouse and back again ten times takes around 9 seconds.

(These times are all slightly approximate, because I'm going by eye, because with 2 hands on the home row I don't have a hand left to operate the stopwatch.)

The longer the shortcut, the more time it takes to activate, of course; here, I picked a nice easy one, in the form of Cmd+C. Maybe that's cheating. Some of the fiddlier emacs shortcuts can be quite time-consuming to enter - the rect ones are particularly bad - C-x r C-w, that sort of thing. I wonder how much quicker those are? But I'd imagine they'll still win out over moving from keyboard to mouse to menu bar and back, since for shortcuts you invoke often, muscle memory takes over and you can rattle them off without even thinking.

Maybe all those piano lessons helped after all.

The reader is invited to use their preconceived opinions about microoptimization to decide which conclusion to draw.

(I have no particular opinion about what to do if your hand is on the mouse to start with. Generally I move it back to the keyboard if I don't know how to do something with the mouse, or leave it there if I do. For things such as moving the cursor, or scrolling, the mouse is very effective anyway; usually effective enough that in many cases it's worth using in preference to the keyboard, if you don't have some non-interactive higher-level motion that you could conceivable invoke, such as M-x forward-sexp, or whatever.)

Re: A Good Vimrc

#100

Post by ownagefool »

scrollaway wrote: post #73
ownagefool wrote: post #60

Earlier quoted context omitted.

You may personally be more efficient but as a team or class our overall efficiency drops by being different. Now I'd argue that the class is more important than you personally. We can agree that it matters a lot less what your own personal setup is as long as it saving stuff in the same format but I wouldn't say it doesn't matter at all. As soon as someone asks you for a bit of help you're going to be slowed down by…

> Finally I'm never going to buy the efficiency of keyboard shortcuts when coding is generally worth the time sink in learning them over clicking a mouse in an IDE. So here's your problem, right. I'm not selling this to you. If I were stating it, I'd be stating it as a fact. Most of HN would agree with it because they themselves experienced it. Indeed the only ones who would disagree with it are the ones "not buying…

Nope, that's where you assume my problem lies. I actually used vim myself for about 8 years as a developer and still generally default to it as my editor doing ops. I just honestly don't think it's generally worth the bother.

That said, I typically wouldn't mandate uniformity either as, as you said, I'd rather work with the curios. I think this ones a crapshoot, but the same folks are much more likely to know a bunch of useful stuff too.

Post reply on HN