Live data from Hacker News

Helping a Million Developers Exit Vim

stackoverflow.blog

461–470 of 489 posts

Re: Helping a Million Developers Exit Vim

#461

Earlier quoted context omitted.

> A lot of the vim "religion" centers around keeping your hands on the keyboard, not using the mouse, carpal tunnel and speed. That's a nice side effect, but it's not why vim is "better". "Normal mode" in vim ties composeable​ functions each to a separate key. The "." key repeats the most recent function. You can record a string of keystrokes to a macro, and even edit it as plain text. Vim is fantastic for editing te…

Editing text is maybe 9% of what I do. Most of my work consists of reading text, thinking about it, running tests, reading the results of those tests, thinking about what I've read, discussing what I've been thinking about with coworkers, reading more text, and thinking some more. It has been this way for most of my career. This is what I see most of my coworkers doing, too. Editing text more efficiently simply would…

> Most of my work consists of reading text, thinking about it, running tests, reading the results of those tests

Vim is quite good at that too, you can set the make program and error format to execute the tests and easily navigate to the source of errors for example.

Re: Helping a Million Developers Exit Vim

#462

Earlier quoted context omitted.

Why doesn't it make sense today?

In all of the discussions on HN about vi/m this is probably the most intelligent question I've received after posting my opinion. I've been coding for 16 hours straight and have at least another four in front of me (have to deliver tomorrow AM) so I don't have a ton of time to answer this. I'll use today as my example of how irrelevant (and counterproductive) vi/m can be. I'm working on a large Django project and cra…

Thanks for the reply.

Certainly, though, you are using PyCharm vi emulation mode?

The interesting thing about your reply is that you focus on productivity/speed. And I think it's hard to argue (though I've seen people attempt to argue this) that time spent moving to/from keyboard is not so relevant considering software development is largely about thinking.

However for me vi-style text entry is not about productivity but about mental comfort. It turns your keyboard into more of a musical instrument and amplifies your ability to express what you want to happen on the screen. That's the case for me. That's why I asked about vi emulation mode, because that's what I think is the salient feature/innovation of vi(m).

Re: Helping a Million Developers Exit Vim

#463

Earlier quoted context omitted.

Hmm, it might have just been because "things like C-x C-c and stuff" sounds kind of dumb, not because it refers to quitting Emacs. Like imagine: B. Kernighan: have you ever used Unix? Student: No. You: Hey, how about we start a Unix tutorial here; we can learn all about dollar-sign-1, and stuff. B. Kernighan : * roll eyes * :)

Surely that is possible too! Either way, it was not my proudest moment.

Time has been kind in gradually fogging out memories of such embarassing moments for me, but not all, unfortunately.

Re: Helping a Million Developers Exit Vim

#464

Earlier quoted context omitted.

I wooed my wife by being able to solve a computer problem as well. Her laptop wouldn't boot, and she had a paper on the hard drive that needed to be submitted that day. "I have just the thing," I said, and I ran home to get my drive-to-USB adapter. Pulled her hard drive, recovered the paper, and printed it from my own laptop. The rest is history.

This is why I keep a tiny bootable USB (Arch Linux) on me at all times. Future wife, here I come!

What if the hard disk is password protected?

Re: Helping a Million Developers Exit Vim

#465
post #316

Earlier quoted context omitted.

THIS is the "How I met your mother" we want.

And I met mine, while she needed help trying to copy paste in emacs. IDE users, you're doomed to stay single!

I love both of the above stories. Mine is not quite as good. My wife was assigned to test my code (Microsoft's CodeView debugger ported to other processors), and one of the reasons she married me was that it didn't introduce new bugs.

Re: Helping a Million Developers Exit Vim

#466

Earlier quoted context omitted.

I wooed my wife by being able to solve a computer problem as well. Her laptop wouldn't boot, and she had a paper on the hard drive that needed to be submitted that day. "I have just the thing," I said, and I ran home to get my drive-to-USB adapter. Pulled her hard drive, recovered the paper, and printed it from my own laptop. The rest is history.

This is why I keep a tiny bootable USB (Arch Linux) on me at all times. Future wife, here I come!

Solid strategy

Re: Helping a Million Developers Exit Vim

#468

Earlier quoted context omitted.

Weelll. The problem is that the "quit" command has an insert mode key in it. So it's quite possible to get stuck like a poster above says- enter macro recording, then insert mode, then write the letter "t". On the other hand that only happens if you type "quit" without the colon and the message makes it very clear that the colon is part of the text you must enter: Type :quit to exit Vim See all that whitespace? It's…

See all that whitespace? It's very hard to think the colon goes to the "Type" bit. Except, logically, why would they bother to specially call out , a whitespace character, but not the spaces as well if they intended the user to type them? I can't think of any obvious, safe way to display text that a user should type that isn't subject to possible misinterpretation in the single line of output available.

Alright, but if we're being so scholastic it should be said that you can misinterpret any set of instructions and in this case, squinting at the command line a couple of times to make sure you got the command right is all it should take you to get it right.

Re: Helping a Million Developers Exit Vim

#469

Earlier quoted context omitted.

Personally, I don't care about "efficiency". I care about usability. Having a tool designed to edit text let's me focus on everything else. Sure, there is a learning curve, but you don't need to be an expert to find the tool useful.

vi wasn't designed to efficiently edit text. It was designed to deal with shitty keyboards of the time. And now it is a cult. I challenge anyone to prove that a non-trivial project, say, a year of work for a team of five developers, would get done any faster, better and with less bugs because of the single act of adopting vim vs. a top grade IDE.

> vi wasn't designed to efficiently edit text.

That's entirely my point. It's not about efficiency. It's a lot like using an alternative keyboard layout. Sure, it isn't faster, but it's a lot more comfortable.

Vim is great for editing text. There are functions that can easily be used to accomplish the editing task you want to do. Having tools designed for the task at hand makes working easier, and more comfortable. It's akin to having more leverage.

> It was designed to deal with shitty keyboards of the time. And now it is a cult.

That's very true. Like many other projects, with age Vim has held to tightly onto tradition. The functions available in normal mode are the same functions bound to the same keys. Any change to that behavior is so fundamental, it simply doesn't happen.

> adopting vim vs. a top grade IDE

That is not what I, or most others are asking. Most people who use vim enter the "vim cult" simply because they enjoy using the tool. Even after decades of stagnation, they prefer vim to an IDE.

If there is something the "vim cult" wants, it is for you to let them use the tool they enjoy. IDEs inherently push tools out of their tightly defined (integrated) ecosystem. If someone wants to use the tool they like, and an IDE, they have to integrate the two. More often than not, that means a minimal implementation of vi inside the IDE.

TL;DR If I am in the "vim cult", you are in the IDE cult. All I want from you is to let people use their tools.

Re: Helping a Million Developers Exit Vim

#470

Earlier quoted context omitted.

Editing text is maybe 9% of what I do. Most of my work consists of reading text, thinking about it, running tests, reading the results of those tests, thinking about what I've read, discussing what I've been thinking about with coworkers, reading more text, and thinking some more. It has been this way for most of my career. This is what I see most of my coworkers doing, too. Editing text more efficiently simply would…

That is precisely my point. To devote any effort at all optimizing this is to go after the wrong optimization target. Just buy or use a good IDE that helps you with tasks beyond text entry and move on. There is no value to be gained doing anything else.

> Just buy or use a good IDE that helps you with tasks beyond text entry and move on.

Why can I not have both?

> IDE

Integrated Development Environment.

Why would you want your compiler and your debugger to implement your editor?

That's like selling a hammer with every box of nails. Sure, I will be using both, but I really like my hammer. The handle feels right in my hand. The balance is just right. Your hammer is cheap and clunky. It may not bother you, but that is no reason for me to use it.

Post reply on HN