Relative Line Numbers in Vim | Hacker News Reader

Relative Line Numbers in Vim

jeffkreeftmeijer.com

58 pointsguiambros38 comments

For the Emacs users, check out https://github.com/coldnew/linum-relative

And for those with the melpa repository set up, it can be found as the "linum-relative" package.

Is this a commonly known feature? Because I have never seen it before. I wish I had been introduced to it about 10 years ago.

I saw it in Learn Vimscript the Hard Way. I assumed it was common knowledge, since I couldn't see any other practical way to use 5j, etc, on a regular basis, but it's apparently less well-known than I thought.

Pre-vim, one would get quite proficient at judging line distances, e.g. 11yy, through practice. Mind you, that was probably helped by text being a fixed size on a serial terminal and bigger than much text today. However, I do wonder if the article is over-promoting movement by lines. Movement commands like ), }, ]], and good old / should be readily considered as well.

Apparently, it has been introduced in 7.3, which is pretty recent.

Yeah I had the same reaction last September when I saw https://news.ycombinator.com/item?id=4496578. But my git history shows I disabled it again a day later. Maybe enabling it just in normal mode will make it stick this time.

The OP says it's new in version 7.3 I also wish it was done earlier since I found myself trying to use commands like '5j' and giving up a long time ago.

Probably worth mentioning numbers.vim (https://github.com/myusuf3/numbers.vim) as an easy plugin to get the relative line numbers going in your vim setup.

I used to use relative line numbers until I learned about dG. For example, I can use 8dG to delete from my cursor to (and including) line 8. Also works with yanking, e.g. 8yG.

Relative line numbers for LIFE! :D

d3j (delete 3 down) and y3j (yank 3 down) do the same things, but relative. I don't even need to look at the relative numbers anymore really. For short hops I just guess. I'm right most of the times.

Absolute line numbers are more convenient for me. Relative line numbers didn't give me any advantage after I learned about the G command. That command is also useful for going to the bottom of the file (G) or to the top of the file (1G). With absolute line numbers I don't have the line numbers changing all the time, which was distracting. It's also easier to open files at a specific line.

gg will take you to the top of the file too

Thanks, learned something new.

I recommend the EasyMotion plugin. It allows you to do this via ,j or ,k (assuming your leader key is set to ,). If you want to move to a specific character in a line you can also use the w/b and f/F motions (with a leading comma).

https://github.com/Lokaltog/vim-easymotion (there's an animated demonstration on the bottom of the readme)

I have used (and like) relative line numbers for a while now. However, when using MacVim full-screen on large (high resolution) screens, the relativenumber and cursorline slow down redraws considerably on my Macs, to the point where it annoys me a lot.

Does anyone else have the same experience and perhaps a solution?

I see considerable slowdown when using just vim on OSX. It could be a fault of something else, but I also find my 'b'ack word slowed down considerably as well.

Yes! Usually it's not a problem, but every now and then relativenumber really kills performance.

The last time I noticed this was with valgrind logs; and I have no idea what exactly is causing it (amount of lines doesn't seem to be it).

Thankfully it's perfectly usuable for day-to-day editing. Binding :set rn! to a key circumvents this problem well enough.

Have you tried the "experimental renderer" feature of MacVim? It made my unbeatably slow MacVim work fine.

Not sure what cursorline is, but relativenumber redraws pretty slowly when scrolling a lot (like jjjjjjjjj) in gVim on a pretty powerful Windows 7 machine. Haven't noticed anything on my linux netbook, but it runs a newer vim version.

Maybe this is not in spirit of VIM, but I set my key repeat to very low value. Minimal setting you can set through mac options is 83 ms - if you press and hold a key it generates a key press every 83 ms. I set up a key repeat to 25 ms through KeyRemap4MacBook (and delay until repeat 150 ms). If I want to generate 1-4 clicks I just press the key repeatedly, otherwise I hold a key.

After some time I got used to it and I can select blocks of text of size 5-10 faster than I would using movement with number (I don't have to move my fingers away, I don't have to calculate or look at the relative distance). Advantage is that it works well outside of vim as well.

Rather than switching between rnu and nu, I simply have `set rnu` and absolute line number in my status line.

I use <line>G to jump to the absolute line. When you need absolute numbers it's mostly because of an error that gave you a line number. You need to jump to it, that's all.

Also :<line> will do that.

"Most testing libraries allow you to run a subset of tests based on their line number by running something like rspec spec/models/user_spec.rb:15."

This sounds... strange to me. When would this be an advantage over some sort of named test? e.g. `manage.py test Thing.validation_test`

> When would this be an advantage over some sort of named test?

Never. "Line number" is very obscure and prone to breaking. "I just added a comment at the top of the file... Whoops! Broke all the tests."

To quote the Zen Of Python—"explicit is better than implicit".

The article is a bit old so I wonder if that is still a common Ruby practice (if it ever was).

Rspec tests aren't simply named "Thing.validation_test", they are generally full sentence descriptions of what the functionality is (eg. "A User that belongs to a valid and paid account should allow creation of projects").

The only time I've ever run specific tests by line-number is when I am working on making that single test green. In cases like that the line-number hardly ever changes (if it does, its because I've modified before filters or added a new `let`).

edit: for a bit more context: that entire string would not be typed in for the single test, it would be built from contexts.

    describe User do
      context "belongs to a valid and paid account" do
        it "should allow creation of projects" do
        end
      end
    end

Step 1: Install https://github.com/tpope/vim-unimpaired

Step 2: Use the convenient 'cor' mapping for toggling 'relativenumber'

Step 3: Marvel at all the other super handy mappings contained within.

Vim 7.3.918 (the version I have installed here on Arch Linux) shows the absolute number of the current line, along with relative line numbers for the other rows. No need for such toggle functions.

Relative line numbers may be useful at first, but they quickly show their limitation when one needs to jump to a specific line.

I find relative numbers distracting (because they change), and don't use them, but that's definitely not a problem in Vim: you can jump to a specific line very easily by typing e.g. "123G", regardless of whether line numbers are visible.

You can jump to a particular line by typing :123

Excuse me, I meant when one needs to know in which line he is.

You should upgrade to patch 787 or above if you can:

http://i.imgur.com/xJ4r75B.png

spf13 is a great plugin bundle for vim that got me started using relative line numbering. It's great for the lazy person who doesn't want to bother setting up all the fancy vim plugins and settings.

https://github.com/spf13/spf13-vim

Lazy persons get the crap they deserve with SPF13.

Polite translation: Take the time to learn how to setup vim yourself and it will reward you 10 fold.

Haha. Yes, that's what I meant. Thanks for your help.

I see two slightly overlapping trends:

1. Alice is intrigued by all the fuss about Vim and tries her best to wrap her head around it by reading online material and "The Fucking Manual" and getting her hands dirty. Because she knows that she can't be as productive as with her previous editor in an afternoon, she learns Vim on the side. Another benefit of that method (and one she doesn't know about at the moment) is that her commitment can be very light at the beginning: when she'll finally decide that Vim is not for her she won't lost anything. If she likes it her commitment will grow with time, as well as her ROI.

2. Bob is a lot into Twitter, blogs, Reddit and HN and he noticed a serious slant of what he perceives as the elite toward Vim (and the screenshots are pretty) so he decides to follow the herd, however weird Vim might be He installs Janus/SPF13/YADR because he has to be a part of the elite right now, no time to setup all those plugins and stuff. After a couple of coderwall posts listing his favorite plugins, Bob will notice that the elite is moving toward Sublime Text, persuade himself and try to persuade others that Vim is too old and, finally, switch.

The two trends are slightly overlapping because a few Bobs are going to turn into Alices along the way. Thankfully, because who wants Bobs in his community?

For the record, I'm a Bob turned Alice.

I came to vim as an Alice. Everyone swore by vim, so I thought I should learn it, despite it being kinda fiddly for a text editor. It took me another couple of years to switch over completely, a couple more before I started to actually enjoy using it, and a couple more before I started to care about being efficient with my keystrokes.

Once you drink the cool-aid, there's nothing quite like it. Sometimes I think that scooting around a text file in vim is my favorite thing about coding.

Reply on news.ycombinator.com