I was at one point <i>very</i> interested in the same idea. I wanted relative line numbers and absolute line numbers integrated together. So, I created a patch, called it `dnu` for "dual line numbering", and sent the suggestion to Bram Moolenaar.<p>Here's what it looked like:
<a href="http://i.imgur.com/NTwwB.jpg" rel="nofollow">http://i.imgur.com/NTwwB.jpg</a><p>Here was the patch. I wrote it back in 2011:
<a href="https://code.google.com/r/justinvh-vim/source/detail?r=c2479730f264091b697932586e085d7199b3173f" rel="nofollow">https://code.google.com/r/justinvh-vim/source/detail?r=c2479...</a><p>Ultimately Bram Moolenaar sent me a reply:<p>"""<p>Justin,<p>I think the audience for this would be too small.<p>- Bram<p>"""<p>However, in 7.3.787 (Jan 2013) a patch was introduced which showed the current line number in :rnu instead of 0. That's definitely in the direction that this patch was going in.<p>So, I didn't get a patch in, but on the plus side, I did learn a bunch about vim's source code.
In the video, the author moves a block of code by:
1. going to the start of the code block
2. changing mode to visual
3. moving to the end of the block
4. deleting the block
5. moving to the insertion point
6. inserting the delete buffer<p>I'd like to suggest that using absolute line numbers shortens this considerably. For example<p>:43,48m63<p>removes lines 43 to 48 and inserts them after line 63 regardless of the current cursor position (no need to move cursor).<p>Not saying relative line numbers are bad, just, there's a quicker way, at least for the demo use case.
I'll ask it again:<p>What is the rationale behind "relative in normal mode and absolute in insert mode"?<p>relativenumber is useful for quick navigation with 6j or 10k or defining a target for operators with c6j or d10k. Relative numbers are a tool for better text editing.<p>number is slightly less useful for navigation when in a large buffer: 6j or v6j are obviously a little better than 4321G or v4321. But I'd argue that the purpose of absolute numbers is more to provide information than to be used as a tool.<p>I've observed that using one or the other is mostly a matter of taste, though, and needs.<p>But the "relative in normal mode and absolute in insert mode" part sounds strange.<p>How are line numbers any useful in insert mode when there's traditionally no editing or cursor movement beyond the same line or <i>maybe</i> a couple of lines above/below?<p>I recently came across a slightly better take on the rnu vs nu "problem",<p><a href="https://github.com/vim-scripts/RelOps" rel="nofollow">https://github.com/vim-scripts/RelOps</a><p>that switches to relativenumber when you hit an operator like c or y and puts you back to number when you are done. This sounds a lot more sensible and less arbitrary to me: you get rnu when it's useful (for defining a target for your operator) and nu elsewhere. Still you get to do 4321G, though.<p>Too bad the author doesn't get as much coverage as this one.
I'm living happily with this:<p>"relative number switches - show numbers in insert mode, relative in normal<p>autocmd InsertEnter * :set number<p>autocmd InsertLeave * :set relativenumber
Nice job with your first vim script!<p>That said, VIM patch 7.3.787 provides a 'better' solution by replacing the current line's number with the absolute number (because seeing 0 on the current line provides nothing meaningful) IMHO:<p><pre><code> with 'relativenumber' can't see the absolute line number
</code></pre>
ftp://ftp.vim.org/pub/vim/patches/7.3/7.3.787
In case you're wondering about the cool status bars for Vim/tmux, it's Powerline: <a href="https://github.com/Lokaltog/powerline" rel="nofollow">https://github.com/Lokaltog/powerline</a>
If it's useful to other people--and obviously it is--it was worth writing, so congratulations on shipping.<p>That said, put me in the category of crotchety old Vim users (even though I'm only 20) who really don't have a use for this. Potential use cases:<p><i>Scrolling:</i> If it's a few lines, I tap j a few times--or guesstimate a number prefix. It's just scrolling--no precision needed. If it's more than a few lines, I use C-d/C-u. If I need to teleport to a line I know about, :<absolute linenum> is fine.<p><i>Yanking/Deleting/Changing/Indenting:</i> I turn on visual line mode (V), and proceed as above. Or, depending on the language I'm in, I'll do, for example, yi{ to yank everything in the current block. Or use () judiciously.<p>So...what's the actual use case for this? Not trying to be critical--I just want to understand how I'd integrate it into my workflow.
This is kinda life-changing. You have now made the use of numeric count prefixes to line-wise operations actually useful. 20dd for example. Delete groups of lines quickly and with precision, without guessing how many lines are involved.
I got to know the numbers plugin from <a href="http://vim.spf13.com/" rel="nofollow">http://vim.spf13.com/</a>
This distribution gets you a really good head start on vim and lets you install additional plugins easily with its VBundle Integration and its customization options.<p>And in case if you ever wondered, why the ESC key is used to change to normal mode, you should read up on the history of the escape key. Therefore I use CTRL-<P> to switch to normal mode, so my hands can stay on the keyboard.
Plugin functionality aside, the use case in the video demo is IMO better addressed by not worrying about line numbers at all.<p>Position the cursor at the start of the function, then d} (delete 1 paragraph forward). Alternatively if you don't have a clean paragraph boundary, use V to start a visual highlight, then move the cursor (up,down,},10down,whatever) to the end, then d to delete.<p>Then } (move 1 paragraph forward)<p>Then p to paste
If the author of the video is reading this: The problem you have with the background color in vim in the beginning of the video can probably be cleared up by making sure your TERM is set correctly.<p>TERM=screen-256color-s cleared it up for me using tmux/urxvt (with 256 colors).<p>(Also, great plugin!)
Tim Pope's unimpaired plugin [1], apart from other very useful key mappings [2], also has a mapping to toggle between relative (cor) and absolute numbering (con).<p>[1]: <a href="https://github.com/tpope/vim-unimpaired" rel="nofollow">https://github.com/tpope/vim-unimpaired</a><p>[2]: <a href="http://vim-doc.heroku.com/view?https://raw.github.com/tpope/vim-unimpaired/master/doc/unimpaired.txt" rel="nofollow">http://vim-doc.heroku.com/view?https://raw.github.com/tpope/...</a>
Same thing for Sublime Text: <a href="https://github.com/tmanderson/VintageLines" rel="nofollow">https://github.com/tmanderson/VintageLines</a>
I used to use Relative Line Numbers, until I switched over to EasyMotion. (Original fork: <a href="https://github.com/Lokaltog/vim-easymotion" rel="nofollow">https://github.com/Lokaltog/vim-easymotion</a>. I use a different fork, but don't have the URL for it ATM).<p>If you haven't tried it, EasyMotion is far, far better and contains much more functionality (covers far more use cases).
I was going to complain this didn't work then I realised my server (Latest Debian stable) only has Vim 7.2 and this requires 7.3. I'm not surprised to find my Mac, which I bought last year, has 7.3 but my server, which I installed last month, has older software.<p>Does anyone know why Debian seems to move so slowly? Should I change to a different distro?
My problem with relative numbering is that it doesn't seem to work correctly when a line is wrapped.<p>Say I want to move 6 lines down. I use 6j, but one of the lines I want to jump over is wrapped and occupies 2 lines in my editor. That will mean my cursor will end up at the line that was previous numbered 5. This behavior drives me nuts.
A nice simple solution. Thanks!<p>Here's something a little more complicated, which may or may not be more useful:<p><a href="http://jeffkreeftmeijer.com/2012/relative-line-numbers-in-vim-for-super-fast-movement/" rel="nofollow">http://jeffkreeftmeijer.com/2012/relative-line-numbers-in-vi...</a>
Honestly, if you already use powerline or familiar extension, you can look at the status bar for the absolute line. I find it's no need for changing between modes.<p>And if you use Mac OSX and latest vim version installed by homebrew, in relative line number mode of vim, instead of 0 it is the row line number.
This is standard in Mathias Bynen's dotfiles that can be found here: <a href="http://dotfiles.github.io/" rel="nofollow">http://dotfiles.github.io/</a>