Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ten Years of Vim

matthias-endler.de

Post reply on HN
Print view View original

91–100 of 123 posts

Re: Ten Years of Vim

#91

Post by stnmtn »

gwn7 wrote: post #28

> I don't use arrow keys to move around in text anymore but forced myself to use h, j, k, l. Many people say that this is faster. After trying this for a few years, I don't think that is true (at least for me). I now just stick to it out of habit. Sounds like he's not a touch-typist. And as a general note; learning and mastering vim can hardly be a pleasant activity for non touch-typists, or otherwise typing heroes.

The best tip i had when using vim is to almost never actually use h or l.

w and b are faster because they move you horizontally between words, so pressing w 5 times will get you to the fifth "word" on a line, and b will go backwards. You only really ever use h or l after getting to the "word" you want, then going over to a letter using h and l.

I still mostly use j and k to move up or down lines

Re: Ten Years of Vim

#92

Post by tom_mellior »

triska wrote: post #87
tom_mellior wrote: post #66

Earlier quoted context omitted.

I need to use Emacs rather than vim for some things (Proof General, mostly), and I was surprised how well evil-mode works. It's only undo that I don't get. From vim I'm used to be able to undo as many editing steps as I want. In evil-mode, I find that if I type "u" too many times, it runs out of undos to do and starts undoing the undos (i.e., it starts re doing things I want to go away). Also, search uses different w…

For linear undo and undo branches, undo-tree.el is required: https://www.emacswiki.org/emacs/UndoTree Regarding "_", you can set up Emacs to treat _ as word constituent by modifying the syntax table . For example: (modify-syntax-entry ?_ "w") For more information, please see: https://www.gnu.org/software/emacs/manual/html_node/elisp/Sy...

Awesome, thanks! I'll try these.

Re: Ten Years of Vim

#93

Post by majewsky »

bArray wrote: post #71
dingaling wrote: post #67

Earlier quoted context omitted.

Most of those are plain vi ( and ed ) commands. All of my machines have the vim-tiny package to stay as close to stock vi as possible. I open and close the editor dozens of times a day to make simple changes and I don't tolerate any lag. I can see that vim would be great for long-form programming but plain old vi was just fine for most admin tasks.

Okay, so I've come across `vim.tiny` a few times now, what's the difference? Plain `vi` I can't seem to work out, the shortcuts I usually use all seem to be different?

vim-tiny differs from regular vim in how much stuff is compiled into it. Regular vim is actually quite hefty since it includes e.g. scripting bindings to Python, Perl, Lua, etc.; or support for X11 (which is useful even in a terminal for working with the X clipboard), and so on. If you have both vim and vim-tiny installed, you can use the command ":version" to compare which features have been compiled in.

Re: Ten Years of Vim

#94

Post by majewsky »

FreeFull wrote: post #59

Nowadays, I prefer Kakoune ( http://kakoune.org/ ) to vim. Being based on selections rather than movements feels much nicer. It feels a bit like always being in a kind of visual mode. That said, there are the following caveats: * Vim tends to be installed/available almost everywhere, Kakoune isn't * Vim has a much bigger ecosystem * There are some very advanced features hidden in vim that most people don't know about…

I've been meaning to look into Kakoune for some time now. How steep is the learning curve for a long-time vim user?

Re: Ten Years of Vim

#95

Post by falcolas »

eadmund wrote: post #52

Wait until he discovers emacs! I don't mean that rudely, it's just that emacs can do everything vim does & far more.

To paraphrase the OP's own words, he likes vim because it treats editing as a first class citizen. Editing in emacs, without something like evil mode, is a second class citizen - it requires key chords to do.

And, if I put on my snark mask for a moment, at the point you're using key chords to do your editing, why limit yourself to emacs? A fully programmable editor is now the norm, not the extraordinary.

Taking my snark mask back off, I realize there are no editors currently which are as fast an extensible as emacs yet; Atom is close, but bloated and slow in comparison.

Re: Ten Years of Vim

#96

Post by hungerstrike »

gwn7 wrote: post #29
spicyusername wrote: post #2

All of the points in the "Some things I wish I could do better" section are the reason I use a regular memorization free-ish IDE. Out of the box the things I want to do are easy (multiple files, manipulating structure of blocks of text, searching and manipulating information across my project simultaneously) and the things that aren't are rare (Add a dollar sign at the beginning of the next 13 lines). I know how to u…

> Out of the box the things I want to do are easy Easy what? Easy to learn or easy to do? They are arguably easier to do in vim once you learn the proper method. Just not as easy to learn. That a common trade-off shared by rather elaborate tools.

Yeah "once you learn the proper method" is the key phrase here. The proper method being "use rote memorization to learn about things which could have easily been made available via some discoverable visual mechanism".

GUIs make things easy to learn and easy to do. Especially on an OS like Windows where you can drive the entire UI with just the keyboard and about a handful of well-known keyboard shortcuts.

So what's your point? Perhaps you're using a Mac or some other barely usable desktop system that has crappy keyboard acceleration for the UI?

Re: Ten Years of Vim

#97

Post by hungerstrike »

Whenever vim comes up I see someone trying to sell the audience on some "amazing", obscure and rarely used feature that users of other editors should be jealous of... However, it seems to me that if anyone actually wanted those features then they'd be standard in other text editors and we'd have them already.

But what I find really hilarious is that whenever these features are mentioned I see people who have been using the thing for a decade say "I never knew that!" or they dicker about what the commands actually are.

Re: Ten Years of Vim

#98

Post by omn1 »

pera wrote: post #38

OP should consider using buffers: you can :ls to display the list of buffers (which I have mapped to gl ) and then :bn (where n is a buffer number) to go to some specific buffer. Also, in the same fashion of gt and gT for tabs, I mapped gb to go to the next buffer, gB to the previous one, and g space to go to the last one. IIRC all these key bindings are unused by default. In my opinion tabs are more useful/interesti…

OP here, will try.

Re: Ten Years of Vim

#99

Post by didymospl »

mattbreeden wrote: post #36
cgag wrote: post #3

It's highly overstated how hard it is to learn imo. I would learn it again without a doubt.

I ran 'vimtutor' twice and felt comfortable enough to switch. I think the only reason people think it's so difficult is they maybe try to go too deep too fast?

I repeated vimtutor for a few days in a row trying to following this nice Vim learning plan [1] I saw on HN and I gave up trying to switch to Vim as my main text editor after that. Even though I knew how to perform most of the basic operations, the fact I had to switch to normal mode to do anything more complex than editing of the current line felt just too unusual to me. I mean, I'm comfortable editing files on remote servers in Vim now but I don't think I'd ever be considerably more productive in Vim than in IntelliJ/Sublime.

[1] https://medium.com/actualize-network/how-to-learn-vim-a-four...

Re: Ten Years of Vim

#100

Post by teilo »

archi42 wrote: post #4

Regarding tabs: I bound F2 to previous tab, F3 to next tab and F4 to new tab. Besides highlighting the current line, I think this is my most important customisation.

Since I rarely do window splits, I finally gave up on tabs and just stick with buffers. Tabs in vim aren't really tabs anyway. They are window layouts. If one tries to treat them like tabs, things can get confusing fast. Using Airline, you can show your buffers in a line at the top of the screen and treat them like tabs, which is nice. I map h and l to move between buffers.
Post reply on HN