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

History and effective use of Vim (2019)

begriffs.com

Post reply on HN
Print view View original

61–70 of 98 posts

Re: History and effective use of Vim (2019)

#61

Post by dbalatero »

sriku wrote: post #6
azalemeth wrote: post #2

I love vim. I am not one of those users who has a huge number of plugins and takes part in an extended eco-system that they perhaps do not fully understand -- for the last ~20 years of my life I have been trying to learn a little more vim each time I use it. I often don't, but it just has so many surprises that when I feel frustrated, I try to work out the "vimmish" way of doing things. Occasionally I give into tempt…

Am a similarly profiled (neo)vim user .. but without cat. Sometimes I catch strange letter combinations like "gqip" in my emails that baffle the recipients. Want vim keys everywhere!

If you want Vim keys everywhere…

A friend of mine I met through my own similar (free) library is developing this like a madman: https://kindavim.app

It costs $3/month (coffee) but for a Vim person like me I gladly pay. Making this work across macOS is a total mess and a full-time job, and it's not trivial work.

If you want a free version, I have https://github.com/dbalatero/VimMode.spoon as a Hammerspoon plugin that works pretty OK, but I'm not actively developing it and prefer the kindaVim app at this point.

Re: History and effective use of Vim (2019)

#64

Post by yjftsjthsd-h »

scruple wrote: post #52
Izkata wrote: post #45

Earlier quoted context omitted.

:set relativenumber The line the cursor is on is now shown in the left sidebar as 0, counting up for each line away from the cursor. So now it tells you what number to use for "10j" and "10k" to move up and down a specific number of lines. m[a-z] `[a-z] Mark a point in a file into a register, and jump back to that point. Or even more interesting: m[A-Z] `[A-Z] Same as above, except capital marks are global and work a…

My only problem with relative line numbers (and I use them despite this) is working with ranges of line numbers. For instance, I'll maybe be doing some refactoring and want to see what it looks like to move lines 127,137 to my current cursor (127,137t.). With relative line numbers I have to do some quick arithmetic to sort out the range.

I believe it's possible to enable relative and absolute numbers at the same time

Re: History and effective use of Vim (2019)

#65

Post by af16090 »

Mildlypolite wrote: post #59
christophilus wrote: post #17

Earlier quoted context omitted.

This is me all the time. The worst is “kkk”. I can’t remember why I type it in vim (it’s muscle memory, and I’m not at a computer to try it out), but it has really bad connotations here in the US south, so… no bueno.

Can I ask what kkk means? I thought it meant that you were laughing like haha (a leas in Brazil) I didn't know it had bad connotations

https://en.wikipedia.org/wiki/Ku_Klux_Klan

Re: History and effective use of Vim (2019)

#66

Post by tomcam »

herodoturtle wrote: post #7
vaylian wrote: post #3

Earlier quoted context omitted.

> You can only imagine how, in command mode, he effectively summons the textual equivalent of the Nine Hells of Ba'ator upon my open documents if I am not quick enough... There's always [u]ndo. Or you can use :earlier 2m to go back 2 minutes in time.

> to go back 2 minutes in time. Wut. ~27 years of using vim, you just blew my mind.

Yeah same. I feel like a new man.

Re: History and effective use of Vim (2019)

#67

Post by vasergen »

SnooSux wrote: post #53
yakubin wrote: post #9

If Vim was a GUI application (and could smoothly handle long lines), it would the perfect editor for me. Alas, the best I've seen so far is Neovim's discontinued GUI frontends.

It's probably not what you're looking for but I find vim bindings for VSCode is a good balance between vanilla vim and an IDE.

I use it as well, it is not 100% compatible, but all the main features that I need (basic things) works fine for me. If somebody stuck with vscode but wants vim key bindings I hightly recommend to try it.

What I noticed that people build "their own" IDE installing and configuring third party plugins and spend a lot of time to maintain this configuration. And there is no guarrantie it will be better then what is already supported in vsCode for example. So as an alternative one can go other way around and just install vim plugin.

Re: History and effective use of Vim (2019)

#68

Post by vbrandl »

galangalalgol wrote: post #22
christophilus wrote: post #17

Earlier quoted context omitted.

This is me all the time. The worst is “kkk”. I can’t remember why I type it in vim (it’s muscle memory, and I’m not at a computer to try it out), but it has really bad connotations here in the US south, so… no bueno.

I always map jj to esc in my vimrc so I don't have to leave the home row. My code in vscode often fails to compile at first because lines end with ;jj

Since I have no use for it, I like to globally (not just in vim) map caps to ESC.

Re: History and effective use of Vim (2019)

#69

Post by galangalalgol »

vbrandl wrote: post #68
galangalalgol wrote: post #22

Earlier quoted context omitted.

I always map jj to esc in my vimrc so I don't have to leave the home row. My code in vscode often fails to compile at first because lines end with ;jj

Since I have no use for it, I like to globally (not just in vim) map caps to ESC.

Not a bad idea, but its still not the home row, and its a weak finger. If I wanted a pinky ginger workout I'd use emacs.

I may still try it out. But decade long habits...

Re: History and effective use of Vim (2019)

#70

Post by tombh »

wruza wrote: post #36
tombh wrote: post #33

Earlier quoted context omitted.

Another issue is scrolling visual lines one by one that have been wrapped. (N)vim can only scroll by literal lines, so if a line is longer than the screen and wrapped, there is no way to step through line by visual line. https://github.com/neovim/neovim/issues/8715

That’s strange. I just tested it and both GVim on windows and vim on a vps linux terminal have no problem with going anywhere on a 170k long line. It lags a little but visually is fine. And just in case you missed it, you may gj gk to navigate visual lines or remap j, k (and , ) to gj gk to make that default. I have a genuine question why use nvim at all if it has such issues with presenting text in a window.

This is about _scrolling_ visual lines. Navigating them as you say, is just fine.
Post reply on HN