Live data from Hacker News

Coming Home to Vim

stevelosh.com

71–80 of 125 posts

Re: Coming Home to Vim

#71
What annoys me about a lot of tech blog posts like this one is that they're essentially voodoo. People like the author write instructions about what you should do without even understanding the instructions themselves.

    "I’m not entirely sure what the filetype lines do. I’ve read that they’re necessary and so far I haven’t had problems."
His example .vimrc has filetype listed twice, which is redundant. This in itself isn't a big deal, but the problem these lines illustrate is.

Sentences like these are the reason for billions of blog posts about setting up an OpenSSL certificate authority all repeating the same example which the documentation explicitly mentions is the wrong way of doing things.

In fact I find that these voodoo instructions often crowd out any actual proper tech guides in the search results, all for the sake of drawing traffic to some blog...

Don't write tech guides if you can't be bothered to do the research and explain to your readers why they should do what you do and what exactly they're doing!

Re: Coming Home to Vim

#72

Earlier quoted context omitted.

Let's say I need to change a word. With Gedit, I double-click the word and retype it the right way. With Vim, I press j until I'm on the line where the word is, then I press w until I'm at the beginning of the word, then I press cw to change the word, retype it the right way, and press escape to go back to command mode. Triple-clicking in Gedit highlights a line. Triple-clicking and dragging highlights a contiguous g…

"With Vim, I press j until I'm on the line where the word is, then I press w until I'm at the beginning of the word, then I press cw to change the word, retype it the right way, and press escape to go back to command mode." OK, this is something Vim people need to work on. Using j/k to move more than one or two lines is the wrong way to do things. I know, I know, we extoll the virtues of hjkl constantly, but really t…

"There are better ways to move around in Vim, such as [f]orward, '[t]il and searching. In your case (changing word XYZ to something else) I would search for the word with /XY… and press return to get there, then edit as you described."

That is both slower and has the disadvantage that any intermediary occurrences of the word between my cursor and the one I want to edit will be accessed first.

"See my previous comment about movement. You'd move to the line you want by using a search (or '{', which moves to empty lines), start your selection with V, and move to the end with another search (or some kind of movement command that gets you where you want to go quickly)."

I invented the following task for myself: With the cursor on a blank line above 4 lines of text followed by a blank line, copy the 4 lines and paste them so that there is a buffer of 2 blank lines between the 4 lines of text and their duplicates. I did the task 4 times in both gedit and vim, restarting whenever I screwed up (which was quite often). Here are my results.

vim: 18.28s gedit: 14.45s

I discarded an earlier task that I think Vim might have been doing better on because the task ended with the buffer back where it started, and I wasn't sure I was able to count accurately while performing the task. However, I had practiced with Vim on that task to the point where my movements were purely mechanical, and I was typing characters nearly as fast as I'm typing these words now.

It's probably a better idea to relax while doing these tasks instead of racing through them, as I'm generally relaxed when I code, but I still don't see much promise in Vim at this point.

As a side note, why is it that I'm the only one doing tests on myself? It's almost as though you guys don't actually want to know which editor is faster.

Re: Coming Home to Vim

#73

Earlier quoted context omitted.

If you say why Gedit was faster perhaps us vim fanatics can help you understand us.

Apple discovered fairly early on that while using a keyboard shortcut seems faster, using the mouse is almost always quicker, even for very advanced users. The illusion stems from how we perceive time when performing the different tasks - we remember time spent searching for the correct target to click, but we forget time spent remembering the right incantation. This paradox is one of the big reasons why I don't use…

That's certainly interesting research, but it's far from conclusive. There are all manner of variables such as the accuracy of the mouse actions required, the number of keystrokes required, the familiarity of the user with the commands, and even the quality of the mouse.

The tests that Apple conducted were based on simple tasks available on the Macintosh computers of the time. However, text editing is a complex task with a lot of room for optimization. There is no doubt that more keypresses can be achieved per second than mouse actions, and that if asked to repetitively perform a task that could be accomplished by means of 10 vim key strokes or some combination of 5 text selections and menu choices, the max speed of the vim'er would top out higher than the mouser.

However true it is that the keyboarder forgets the time spent recalling arcane commands, it's also true that experienced vim'ers can issues multiple commands per second, some of which will do things that would not reasonably contained in a convenient location in a menu and/or icon-based interface. The powerful grammar and compositional nature of vi commands alluded to in this article, combined with the patterns that emerge in working with specific programming languages lead to opportunities to develop extremely efficient editing skills that blow a mouse-based workflow out of the water. It's not just my own experience, it's watching other people do things in vi or emacs that I guarantee are impossible with a mouse.

You may well be right that the improved productivity of vi/emacs is exaggerated by its practitioners, but I don't think there's really a case to be made that advanced keyboard editing is a waste of time.

Re: Coming Home to Vim

#74

Earlier quoted context omitted.

Let's say I need to change a word. With Gedit, I double-click the word and retype it the right way. With Vim, I press j until I'm on the line where the word is, then I press w until I'm at the beginning of the word, then I press cw to change the word, retype it the right way, and press escape to go back to command mode. Triple-clicking in Gedit highlights a line. Triple-clicking and dragging highlights a contiguous g…

Reading your comment it is apparent you dont now "enough" vim. It has a long learning slope with many comfortable plateaus. You must be diciplined and interested in mastering your tools to push beyound these. fyi, :set paste :set nopaste

In my Vim vs Gedit test, I was doing tasks from the beginning of the Vim tutorial using the exact commands the tutorial told me to use.

It does seem possible to me that someone could become faster with Vim than a click-and-type editor, but I'd guess they'd never amortize the costs of their learning. (Of course, if you're already quite advanced then you've paid a good chunk of the cost and it may make sense to continue.)

Re: Coming Home to Vim

#75

After a few months of vim use, I did part of the vim tutorial using both vim and a click-and-type editor (gedit) and timed myself. Gedit was significantly faster. Can't say I understand you vim fanatics.

Few months of vim use is not really enough to see major benefits in raw speed. You have to get not just the basics but the advanced movement/replacement commands in your bones. A click-and-type editor will start you off fast and top out quickly. You can also use vim as if it were TextEdit, mostly, and the gradually add the advanced features, as per wycats. Best of both worlds.

[deleted]

Re: Coming Home to Vim

#76
A bit off the topic but a couple of doubts regarding pathogen. I installed pathogen and am a bit confused regarding the organisation of the plugins within pathogen. Say I have plugin called foo.vim, inside the bundles folder do I directly drop it or do I create a folder called foo and then drop foo.vim within it? Also say a plugin has syntax files and an ftplugin folder then do I just drop the plugin in pathogen and it is supposed to work? Is there any good doc out there explaining how to configure with pathogen?

Re: Coming Home to Vim

#78
post #57

Earlier quoted context omitted.

Let's say I need to change a word. With Gedit, I double-click the word and retype it the right way. With Vim, I press j until I'm on the line where the word is, then I press w until I'm at the beginning of the word, then I press cw to change the word, retype it the right way, and press escape to go back to command mode. Triple-clicking in Gedit highlights a line. Triple-clicking and dragging highlights a contiguous g…

Since you seem to compare terminal vim vs gedit: How do you run gedit in a terminal? I gvim you could have used the mouse too.

Really what I'm wondering is whether the Vim way of doing things or the click-and-type way of doing things is faster. I don't see any really compelling advantages of Vim as a click-and-type editor. Gedit also has a plugin mechanism y'know.

Re: Coming Home to Vim

#79

I dont see the appeal of nerdtree and the like. For me they are clumsy and too much information. I'm very adept at unix cmd line, find, ack, locate, CDPATH, cmd history, and friends. I spend 10-20% of my editing time at the bash prompt. So much so i aliased :e to vim Having never got the "gui" file managemnet tools i cant say for certain but i wonder if power and productivity gains one sees from truly learning vim ca…

Could you please share how exactly you do the "jump to file foo.bar" functionality? That is the only part of vim I still find a bit laborious, probably because I haven't found a good workflow for it.
Post reply on HN