another update for the 'relativenumber' feature.
After setting this option, relative line numbers are shown on the left side of
the window. The line with the current cursor shows 0, lines further up or down
show the difference of the line to the line with the current cursor. That
leads to increasing numbers 0, 1, 2, 3, ... in both directions (up and down).
The appearance is similar to the 'number' option (absolute line numbers).
Relative line numbers help you using the [count] you can precede some vertival
motion commands (e.g. j k + -) with, without having to calculate it by
yourself. Especially useful in combination with other commands (e.g. y d c < >
gq gw =).
Apply the patch:
patch -p0 < vim-7.2-relativenumber.patch
Use the feature:
Now enjoy the use and the power of the [count] mechanism.
Initial discussion started on 13.02.2008 on the vim_dev mailing list with
the title "feature request: help users count lines - display relative line
Discussion continued on 27.06.2008 with the title "updated 'relativenumber'
There is a little scepticism but more sympathy for the feature, but it didn't
get into mainline Vim 7.2.
I'd appreciate some feedback. I'd like to know who likes the feature and uses
or already used it, and who likes the idea of the feature without having
tested it, for example because of having to compile Vim on his own.
I'd fall into the last group. I would love this feature, and would
probably use it a lot (even going so far as to map a single key to
toggle it on and off), but I don't see myself ever compiling my own
Vim. On Windows, an installer is much simpler for me, and on Ubuntu I
just use the package manager.
> I'd appreciate some feedback. I'd like to know who likes the feature and uses
> or already used it, and who likes the idea of the feature without having
> tested it, for example because of having to compile Vim on his own.
I did test it, but did not bake my own 7.2 (yet?). I like it and would
use it from time to time. Same as Benjamin, I would even map a key to
I am not sure if Bram ever commented on the patch in its current state?
Your patch and the floating point patch made me think of the whole
Vim-mm concept, again. A single Vim in which a few patched could be
integrated & tested. Bram, could such a beast perhaps even help you by
providing a place to drop larger patches in for testing? Or would you
rather not use something like this in case vanilla Vim and the patched
version behave differently and you get bogus results?
Couldn't patches be uploaded to the "scripts" secttion of vim-online?
Maybe an additional category could be added? Or else, a section, or even
a "sister project", of the Vim wiki? (Vikisource? ;-) )
It's more than magnificent -- it's mediocre.
-- Sam Goldwyn
The build fails if --with-features=small is used:
screen.c:(.text+0x225c): undefined reference to `get_cursor_rel_lnum'
That's because get_cursor_rel_lnum depends on either FEAT_VIRTUALEDIT or
PROTO (src/misc2.c:19), and there is no appropriate check when
get_cursor_rel_lnum is called (src/screen.c:2221).
I am not familiar with vim sources, can't think of how this shoud be
http://www.mysza.eu.org/ | Everybody needs someone sure, someone true,
PLD Linux developer | Everybody needs some solid rock, I know I do.
The patch shouldn't depend on FEAT_VIRTUALEDIT, I just put the function
get_cursor_rel_lnum() somewhere into src/misc2.c without thinking about a
problem. But I wonder why I put it exactly there!? Now I've moved it.
Thanks for reporting.
For patches like this, with a small audience and questionable positive
effect, it's perfectly fine to distribute them separately. You could
also make a project on SourceForge or code.google.com to distribute the
I hesitate to include patches like this. Experience in the past shows
that quite often these things cause trouble, more than would be
indicated by the small group of people using it until now. Worst is
when the original author disappears, then I end up having to fix
Most things can be done with Vim script, and if not then I often look at
a few generic things that can make it possible to do this with a Vim
script. I have done this for the Netrw plugin and it turns out this
works well. It doesn't work for the relativenumber patch though.
The most powerful force in the universe is gossip.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
He did on the last update 6 weeks ago:
"I can see it's somewhat useful, but it's also a "yet another option" thing."
I see it the opposite way around:
It's not another option, that every full-blown editor wants to have. It's an
option that only makes sense in an editor like Vim.
> Your patch and the floating point patch made me think of the whole
> Vim-mm concept, again. A single Vim in which a few patched could be
> integrated & tested.
It's one month ago, since Christian Michon set up the "git from scratch
repository". He also thought on this with this repository. Then he went on
holidays for 4 weeks. He planned to continue with the git repository, but I
don't know the current state.
I think both would be needed: Version control for development, adjustment to
the base source tree and merging together. And an interface for downloading
> Couldn't patches be uploaded to the "scripts" secttion of vim-online?
> Maybe an additional category could be added? Or else, a section, or even
> a "sister project", of the Vim wiki? (Vikisource? ;-) )
Yes and no. The idea is to have a prebuilt binaries etc, at some point.
I.e. a drop-in replacement that just happens to be a testing ground for new
features and a place to keep patches that will never make it into mainline.
Think Vim-Shell, for example.
> What conscept is that?
linux-mm is a tree by Andrew Morton. It is a testing ground for new
stuff that does not yet make it into Linus' tree. So this would basically
be a Vim with experimental features.
> Wouldn't the branching features of version control software be good
> for this? I don't have much experience with them.
On the one hand, this would mean that Bram would need to be
willing to give people write access to a branch in his repo so they
can do anything in that specific repo.
On the other hand, some systems handle merging better than
others. CVS sucks at merginf, SVN has gained new feature in
that regard recently.
Much as I hate to say it, in this case a git repo might be the
way to go for various reasons..
Works now, thanks.
And do you realize that the vim script has some limitations that can't be
overcome and that the patch is older than the script?