Live data from Hacker News

Vim clutch

github.com

171–180 of 227 posts

Re: Vim clutch

#171

Earlier quoted context omitted.

> I would like to get a list from him (or her). Why is an answer from sofal not acceptable?

Funny enough, not one person is stepping up to the plate to justify and quantify the claims that vi/vim are/have "highly efficient text-editing capabilities". Numbers. Not statements or links to the manual. I care about data. Show me a project that got done sooner and better because of the use of vi/vim and you'll have a point. I propose that not one person can make that claim and that the popularity of vi/vim are pu…

Mate, I was just asking why you are demanding an answer from one particular contributor.

Regardless, see this: http://news.ycombinator.com/item?id=4144499

Furthermore, "the other has to use command line and vi/vim. " seems to be confused. Using vi style editing does not really have anything to do with the command line (though it frequently does, that is out of choice, not necessity).

Re: Vim clutch

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

Regarding emacs pinky , many people find remapping CAPSLOCK to CONTROL helps quite a bit. Here is one popular xmodmapping: remove lock = Caps_Lock remove Control = Control_L keysym Caps_Lock = Control_L add lock = Caps_Lock add Control = Control_L

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.

Re: Vim clutch

#174
post #141

Earlier quoted context omitted.

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

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

ijkl sounds good, but it would break my habits for when I play nethack...

Re: Vim clutch

#175
post #168

Earlier quoted context omitted.

My very first comment gave some (superficial) explanations. I didn't think that I needed to write a small term paper to voice an opinion. As for down-voting on HN. There's plenty of evidence that it is badly broken. It's funny to watch the Apple fan-boys down-vote on emotion when you even peripherally chafe their idols. The emotion is evident from the fact that substantive posts are down-voted when nothing is materia…

Trollish nonsense. You haven't even really read my comment, or you'd know that the leverage ratio I mentioned, which you're challenging me to justify, was actually about the efficiency of the tools you yourself were touting, not vim. Your "conclusions" are obviously trolling.

I truly don't enjoy the personal attacks.

You win. Done.

Re: Vim clutch

#176

I did this a few months ago: imap kj I have never had to type a word with the letter combination 'kj' in it. Works great.

That's going to suck when you get lockjaw playing blackjack in Reykjavik. But other than that, you seem pretty safe.

Re: Vim clutch

#177
post #135

Earlier quoted context omitted.

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

Just :set relativenumber You won't have to count anymore.

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

Re: Vim clutch

#178

Earlier quoted context omitted.

Because I am arguing that the purported efficiency gains from the use of vi/vim are insignificant in the context of a non-trivial project. Far more time can be gained (or lost) through activities that have nothing whatsoever to do with text editing. As an optimization problem, text editing is the wrong aspect of creating a software product to focus on. Software projects are notorious for being way behind schedule. If…

> "efficiency gains from the use of vi/vim are insignificant in the context of a non-trivial project" They are important to programmers . You are arguing against a strawman that I suspect you do not even realize you have constructed.

Here's opinion from the horse's mouth:

Back in 1999, the mag asked Joy what inspired him to write vi:

What happened is that Ken Thompson came to Berkeley and brought this broken Pascal system, and we got this summer job to fix it. While we were fixing it, we got frustrated with the editor we were using which was named ed. ed is certainly frustrating.

We got this code from a guy named George Coulouris at University College in London* called em - Editor for Mortals - since only immortals could use ed to do anything. By the way, before that summer, we could only type in uppercase. That summer we got lowercase ROMs for our terminals. It was really exciting to finally use lowercase.

So we modified em and created en. I don't know if there was an eo or an ep but finally there was ex. [laughter] I remember en but I don't know how it got to ex. So I had a terminal at home and a 300 baud modem so the cursor could move around and I just stayed up all night for a few months and wrote vi.

Linux Mag then asked: "So you didn't really write vi in one weekend like everybody says?"

No. It took a long time. It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. It was just barely fast enough. A 1200 baud modem was an upgrade. 1200 baud now is pretty slow.

9600 baud is faster than you can read. 1200 baud is way slower. So the editor was optimized so that you could edit and feel productive when it was painting slower than you could think. Now that computers are so much faster than you can think, nobody understands this anymore.

This is from Bill Joy, who wrote vi. The last line is very much on point and mirrors my point of view: "Now that computers are so much faster than you can think, nobody understands this anymore."

Also: "I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem."

If one was given the task to write a text editor today, even one without a GUI, I would be surprised if anyone reached for some of the things Bill had to do in the context of 300 baud modems and a terminal (not window, but physical).

In the context of large projects vi/vim don't offer any real measurable gains. The fact that programmers who take the time to learn these tools feel good about them does not constitute proof of anything other than that fact.

Let's just agree to disagree and move on.

Re: Vim clutch

#179
post #168

Earlier quoted context omitted.

Trollish nonsense. You haven't even really read my comment, or you'd know that the leverage ratio I mentioned, which you're challenging me to justify, was actually about the efficiency of the tools you yourself were touting, not vim. Your "conclusions" are obviously trolling.

I truly don't enjoy the personal attacks. You win. Done.

You've written hundreds, if not thousands, of words in response to this article (about a neat hardware hack lets remember. You've been on a tangent since square one...) accusing vi users of "being tribal" and "drinking cool aid", pounding your own chest, attacking the HN voting system, and in general just doing your damnedest to start yet another editor flamewar.

Then somebody suggests that you are acting trollish, and to you that is simply uncalled for.

Really?

Re: Vim clutch

#180

Earlier quoted context omitted.

> "efficiency gains from the use of vi/vim are insignificant in the context of a non-trivial project" They are important to programmers . You are arguing against a strawman that I suspect you do not even realize you have constructed.

Here's opinion from the horse's mouth: Back in 1999, the mag asked Joy what inspired him to write vi: What happened is that Ken Thompson came to Berkeley and brought this broken Pascal system, and we got this summer job to fix it. While we were fixing it, we got frustrated with the editor we were using which was named ed. ed is certainly frustrating. We got this code from a guy named George Coulouris at University Co…

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 impression that when people talk about editing efficiency that they are meaning to imply business efficiency. This is what I was saying when I said you have constructed a straw man.

Post reply on HN