Live data from Hacker News

Vim Creep

rudism.com

131–140 of 237 posts

Re: Vim Creep

#131
post #112

Earlier quoted context omitted.

Although I agree with you, IDE fans feel the same way: "Writing code is a solved problem: eclipse or xcode or visual studio. Pick one based on your environment and get back to work" An argument I hear a lot is: 'vim is fine for editing files on a remote server, but not suitable for everyday work'. I believe it is a common belief outside of the HN crowd.

On IDEs: I have the 'pleasure' of being one of those chaps who spends parts of his day job reworking massive Java projects. There is no way in hell I'm touching that without an editor that deeply understands Java.

There are multiple variables in your equation. You may be altering the wrong one.

Re: Vim Creep

#133

This feels like an article about a religion or cult, not a software program. I just don't get it. Ever since newer editors got block editing or multiple insertion cursors, and RegEx find & replace across multiple files, and searching filenames to open... I feel like I've already got everything I need! What am I missing out on? I don't feel like my text editor holds back my productivity. Using something like Sublime,…

It's all about building up a maximally powerful keyboard text editor from potent primitives. When it comes to out-of-the-box editors, nothing gives more bang for the buck on arbitrary text files than vim.

That's not to say it's the best overall. If you like to customize your environment, emacs is better. If you like tight OS integration and advanced GUI features, many editors are better. If you want the most productive environment for a specific programming language then some IDE is probably better.

But when it comes to raw keyboard editing, why is vim so powerful?

Well, it starts with normal vs insert mode. Because insertion is a specific mode, it means every single key on the keyboard is available for direct editing commands. Of course you can have modifier commands as well, but that's nowhere near the convenience and efficiency of plain typing.

So right off the bat you start with an order of magnitude more command possibilities in an easier to access position (chordless). The commands of the basic keys are designed to be a solid fundamental set of building blocks for all common editing tasks, and they are assigned mnemonically.

The power of the fundamental commands is then multiplied by the vim grammar, whereby commands are applied to objects, which again are a terse and mnemonic description of some chunk of the file.

In practice this means that very short unmodified alphanumeric strings you type can produce powerful changes. It's not just keystroke-counting, it's the fact that these keystrokes are also a meaningful language that makes sense mnemonically, not just through muscle memory. The more you practice, the more different ways you start to see to effect a given change. As you become more proficient, you can do more and more with a single command.

This is important because commands are atomic, and you can repeat the previous command by hitting '.'. The power of this isn't really apparent until you grok the breadth of things a single vim command can do, but have you ever wanted to do a regexp search and replace and spent a long time crafting it and still had to step through it because you were afraid it might screw something up? With vim commands you can often times use simple command repetition to avoid complex regexps ('n.n.n.n.n.n.n.n.' to find next/repeat command).

Sometimes I'm surprised by the mileage I get out of that, but it's really the tip of the iceberg. Because you also have macros, which are just recorded sequences of commands. But the cool part is that commands are made up mostly of regular characters, so the macros look like plaintext, and vim treats them that way as well. Vim has 26 clipboards called registers, and these registers function both as text storage and executable macro space. Meaning you can record a macro, and then paste it into a buffer, and tweak it via normal text editing, and then pull it back in and run it. Because the commands are so simple and mnemonic, it's actually astonishingly easy to do this. Once you are comfortable with it, you find yourself recording, running and dropping macros in less than the time it takes to write a single regexp. I have spacebar bound to a specific quick-macro slot so I can record and then hold down space to mass-apply a macro (my key repeat-rate is maxed as well :), this lets me do the types of things in seconds that previously would have me busting out the sed/awk book. It's very hard to communicate the impact this has on your editing workflows to someone who doesn't get it. It's sort of like a git user telling a svn user why easy branching is so awesome, the svn user just doesn't get it because they've already convinced themselves they don't need branches precisely because they are so hard to use.

In short, the vim advantage is about powerful editing primitives and easy ways to compose them. There are certainly many great editing ideas that are not in vim, but in terms of the fundamentals for keyboard editing, it's hard to imagine anything better.

Re: Vim Creep

#134
post #123

Earlier quoted context omitted.

For me, it's about the interface. In descending order: intuitive, consistent, modular, comfortable, portable. Intuitive: most commands resemble natural language, without awkward or arbitrary mappings. For instance: - w: (forward) word; - cw: change (forward) word; - c2w: change 2 (forward) words; - 2cw: twice change word; - ciw: change inner word; There is no intervening translation. For instance, to change a word in…

I'm sorry, but although I'd agree vim is awesome, there's no way I would call its commands "intuitive." Take 'y', for 'yank.' Would anyone really argue that the word "yank" is a natural way of expressing "copy?" "Yeah mom, just yank and paste that into an e-mail... " And there's nothing inherently intuitive about '/' for searching, unless you're already familiar with unix commands like sed. Or ":" for go to line. Or…

It's not that individual commands are intuitive. Yes, you need to learn the verb for copying is y (and is called yank), the verb for deleting is d. The "intuitive" part comes once you have a basic vocabulary. You can then learn a new action and already "intuitively" know advanced ways to use it.

If I learn the new verb c, which deletes and puts me in insert mode, I already know that I can type c3w to change 3 words, or ci" to change the phrase inside quotation marks.

Because all verbs work on the same set of nouns and adjectives I can intuitively know what many commands do - even though I've never tried them - as long as I understand the parts that make up the command.

Re: Vim Creep

#135
post #121
post #104

Earlier quoted context omitted.

And he end it with :wq This part make me smile... Wonder what others tough when see that?

For rhetorical effect, `:wq` is right. But in the real world, `:x` is the better choice.

I've been using vim for years and didn't know about :x. go figure.

Re: Vim Creep

#136

I've said it before, and I'll say it again... Editing text is a solved problem: vim or emacs. Pick one and get back to work.

Oh please...

    "Ed is the standard text editor." 
    
    And ed doesn't waste space on my Timex Sinclair.

Re: Vim Creep

#137
post #121
post #104

Earlier quoted context omitted.

And he end it with :wq This part make me smile... Wonder what others tough when see that?

For rhetorical effect, `:wq` is right. But in the real world, `:x` is the better choice.

Pft. What rhetorical effect? `:x` is always the better choice. :P

Re: Vim Creep

#138
post #121
post #104

Earlier quoted context omitted.

And he end it with :wq This part make me smile... Wonder what others tough when see that?

For rhetorical effect, `:wq` is right. But in the real world, `:x` is the better choice.

I disagree for the following reason: I think of :w and :q as two concepts, and :x adds a third, which I personally feel adds some cognitive load, like I now have to differentiate between wanting to write, wanting to quit, and wanting to do both at the same time. With :wq it feels to me like I'm deliberately saying "let's write and then quit".

Muscle memory is not likely to kick in anyway because I almost always use :w and :q separately. I'm modifying the file in one tmux window and compiling/running it in another, so I keep the file open in vim. I don't want to replace :q with :x because I want to be alerted if I've made some changes that haven't been written yet, because that means I may have neglected to test them.

Re: Vim Creep

#139
post #121

Earlier quoted context omitted.

For rhetorical effect, `:wq` is right. But in the real world, `:x` is the better choice.

I've been using vim for years and didn't know about :x. go figure.

The only time I type :wq is when it's by accident that my finger hits both keys at once. I hate it.

Re: Vim Creep

#140
post #90
post #71

Earlier quoted context omitted.

I think it's better to use grep. Knowing the options to apropos has very low value. Knowing grep has lots and lots of value.

I agree. I have no idea how to use `find`. I always do `find . | grep whatever`, since I know the basics of grep.

Learning find is a worthy investment.

    find ./ -name "*.log" -size +2G -ctime +3 | xargs -P 8 gzip
Will find all log files over 2 gigs and older than 3 days. Then it will gzip them split across 8 parallel gzip processes.
Post reply on HN