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.
Vim Creep
131–140 of 237 posts
Re: Vim Creep
#132Thanks all.
Re: Vim Creep
#133This 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,…
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
#134Earlier 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…
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
#135Re: Vim Creep
#136I'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.
"Ed is the standard text editor."
And ed doesn't waste space on my Timex Sinclair.Re: Vim Creep
#137Re: Vim Creep
#138Earlier 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.
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
#139Earlier 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.
Re: Vim Creep
#140Earlier 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.
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.