New feature: absolute line number in relativenumber for the current line

1,910 views
Skip to first unread message

Paul Ruane

unread,
Jan 29, 2013, 5:21:33 AM1/29/13
to vim_dev
Hi,

I asked on the Vim reddit (http://www.reddit.com/r/vim/comments/
17gg56/) if anyone knew how to achieve this with existing
functionality or plug-in but apparently not. I would simply like to
have the option, when relativenumber is turned on, to have the current
line show the absolute line number rather than zero. Is this a
reasonable suggestion?

Whilst it is not that hard to scan the status line, I find that I hit
this glitch in my workflow many, many times a day: when I want to know
what line I am on, I intuitively scan the gutter for the line number.
I then realise that relativenumber is on so I redirect my attention to
the status line and then have to parse the number from the other
fields down there.

Many thanks,
Paul.

Nazri Ramliy

unread,
Jan 29, 2013, 9:51:01 AM1/29/13
to vim_dev
On Tue, Jan 29, 2013 at 6:21 PM, Paul Ruane <paul....@oniony.com> wrote:
> Whilst it is not that hard to scan the status line, I find that I hit
> this glitch in my workflow many, many times a day: when I want to know
> what line I am on, I intuitively scan the gutter for the line number.
> I then realise that relativenumber is on so I redirect my attention to
> the status line and then have to parse the number from the other
> fields down there.

The following patch does what you want. After trying it out for a few minutes
it does feel easier to find out the current line number. I normally
have the line
number in my statusline, and on the occasion where the statusline is not shown
I've trained my fingers to hit Ctrl+G and scan the bottom line for the
line number.

Having the current line number, instead of a '0' shown at the current line seems
more useful. For better distinction the current line number ca be left-aligned
(for left-to-right text orientation) to make it look different than the
relative-line-numbers (I made no attempt at this in the patch below).

Others might find it weird.

patch follows:

--8<--
diff -r 990d0f9400dc src/misc2.c
--- a/src/misc2.c Sat Jan 19 14:02:02 2013 +0100
+++ b/src/misc2.c Tue Jan 29 22:36:00 2013 +0800
@@ -515,7 +515,7 @@
#endif
retval = lnum - cursor;

- return retval;
+ return retval == 0 ? lnum : retval;
}

/*
diff -r 990d0f9400dc src/screen.c
--- a/src/screen.c Sat Jan 19 14:02:02 2013 +0100
+++ b/src/screen.c Tue Jan 29 22:36:00 2013 +0800
@@ -10238,12 +10238,7 @@
int n;
linenr_T lnum;

- if (wp->w_p_nu)
- /* 'number' */
- lnum = wp->w_buffer->b_ml.ml_line_count;
- else
- /* 'relativenumber' */
- lnum = wp->w_height;
+ lnum = wp->w_buffer->b_ml.ml_line_count;

if (lnum == wp->w_nrwidth_line_count)
return wp->w_nrwidth_width;
-->8--

Nazri

Charles Campbell

unread,
Jan 29, 2013, 11:18:28 AM1/29/13
to vim...@googlegroups.com
:he 'number'

set nu is shorter than
set rnu

Admittedly, this is not shown when relativenumber is enabled and number
isn't, but the number option appears to have priority. Of course, its
not merely showing numbering for just the current line, either.

One issue about generally doing this is that relative numbering only
reserves three spaces (how many people have over 100 rows on their
monitors? just wondering), but files often have many more lines that
that. Hence the gutter needs to be expanded, resulting in loss of
valuable screen estate. I'd be willing to put it into my RltvNmbr
plugin, but it uses signs to display relative numbering, and those are
limited to two characters per line.

Regards,
C Campbell

Ben Fritz

unread,
Jan 29, 2013, 12:36:45 PM1/29/13
to vim...@googlegroups.com, charles.e...@nasa.gov

I think '0' adds no value but an absolute number for the current line only would be useful. I keep rnu set and rarely set nu.

In the meantime, I'd suggest creating a mapping to toggle between rnu, nu, and nornu nonu.

Christian Brabandt

unread,
Jan 29, 2013, 12:46:57 PM1/29/13
to vim...@googlegroups.com
That indeed looks like a helpful extensions, but I suggest to
highlight the current (absolute) linenumber differently, otherwise
it might be confusing in a file with the cursor at the top:

1 foobar
1 blah
2 fasel

regards,
Christian

Bram Moolenaar

unread,
Jan 29, 2013, 4:33:42 PM1/29/13
to Nazri Ramliy, vim_dev

Nazri Ramliy wrote:

> On Tue, Jan 29, 2013 at 6:21 PM, Paul Ruane <paul....@oniony.com> wrote:
> > Whilst it is not that hard to scan the status line, I find that I hit
> > this glitch in my workflow many, many times a day: when I want to know
> > what line I am on, I intuitively scan the gutter for the line number.
> > I then realise that relativenumber is on so I redirect my attention to
> > the status line and then have to parse the number from the other
> > fields down there.
>
> The following patch does what you want. After trying it out for a few minutes
> it does feel easier to find out the current line number. I normally
> have the line
> number in my statusline, and on the occasion where the statusline is not shown
> I've trained my fingers to hit Ctrl+G and scan the bottom line for the
> line number.
>
> Having the current line number, instead of a '0' shown at the current
> line seems more useful. For better distinction the current line number
> ca be left-aligned (for left-to-right text orientation) to make it
> look different than the relative-line-numbers (I made no attempt at
> this in the patch below).
>
> Others might find it weird.

I think the information is useful. Who is against showing the current
line number instead of zero?

Is the width of the column a problem?

--
"Hegel was right when he said that we learn from history that man can
never learn anything from history." (George Bernard Shaw)

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Charles Campbell

unread,
Jan 29, 2013, 5:48:18 PM1/29/13
to vim...@googlegroups.com
Bram Moolenaar wrote:
>
> I think the information is useful. Who is against showing the current
> line number instead of zero?
>
> Is the width of the column a problem?

Not if its optionally a part of relative numbering.

Regards,
C Campbell


Ben Fritz

unread,
Jan 29, 2013, 9:18:06 PM1/29/13
to vim...@googlegroups.com, charles.e...@nasa.gov

I only rarely edit files with 10000 or more lines. Most of the time for me, my 'rnu' column takes 4 columns, and my 'nu' column takes 5. I don't care about the extra width, and would probably never turn off the option to show the absolute number on the current line if there were such an option. I'd support doing it that way always, but I'd accept an option as well.

Nazri Ramliy

unread,
Jan 30, 2013, 2:07:51 AM1/30/13
to vim_dev
On Tue, Jan 29, 2013 at 10:51 PM, Nazri Ramliy <ayie...@gmail.com> wrote:
> For better distinction the current line number ca be left-aligned
> (for left-to-right text orientation) to make it look different than the
> relative-line-numbers (I made no attempt at this in the patch below).

Here's a new patch that makes an attempt at the above. When rnu is on,
the current line number is flushed left, like this:

1 diff --git a/src/screen.c b/src/screen.c << Cursor at this line
1 --- a/src/screen.c
2 +++ b/src/screen.c
3 @@ -2319,6 +2319,7 @@

Which distinguishes the current line number from the relative ones -
this makes it much much easier to differentiate between the two.

In this new patch the logic for deciding whether to show the current
line or '0' is done outside of get_cursor_rel_lnum() which preserves
the function's original purpose.

I'm attaching the patch (instead of inlining it just so that gmail
doesnt' change the tabs into spaces).

While coming up with this patch I noticed that the formatting of the
line numbers (regardless of whether 'nu' or 'rnu' are set) are not
changed at all in right-to-left ('rl') mode - the single space that
separates the line numbers and the text are not placed in between the
two in right-left mode. I'm guessing that this is a bug.

Nazri
currlinenumber.patch

Christian Brabandt

unread,
Jan 30, 2013, 3:39:40 AM1/30/13
to vim...@googlegroups.com
Nice. Here is your patch updated and using the CursorLineNr highlighting
for the line the cursor is on.

regards,
Christian
currlinenumber.patch

Bram Moolenaar

unread,
Jan 30, 2013, 6:31:53 AM1/30/13
to Nazri Ramliy, vim_dev

Nazri Ramliy wrote:

> On Tue, Jan 29, 2013 at 10:51 PM, Nazri Ramliy <ayie...@gmail.com> wrote:
> > For better distinction the current line number ca be left-aligned
> > (for left-to-right text orientation) to make it look different than the
> > relative-line-numbers (I made no attempt at this in the patch below).
>
> Here's a new patch that makes an attempt at the above. When rnu is on,
> the current line number is flushed left, like this:
>
> 1 diff --git a/src/screen.c b/src/screen.c << Cursor at this line
> 1 --- a/src/screen.c
> 2 +++ b/src/screen.c
> 3 @@ -2319,6 +2319,7 @@
>
> Which distinguishes the current line number from the relative ones -
> this makes it much much easier to differentiate between the two.
>
> In this new patch the logic for deciding whether to show the current
> line or '0' is done outside of get_cursor_rel_lnum() which preserves
> the function's original purpose.
>
> I'm attaching the patch (instead of inlining it just so that gmail
> doesnt' change the tabs into spaces).

This looks like a good solution. I'll include it. With Christian's
addition.

> While coming up with this patch I noticed that the formatting of the
> line numbers (regardless of whether 'nu' or 'rnu' are set) are not
> changed at all in right-to-left ('rl') mode - the single space that
> separates the line numbers and the text are not placed in between the
> two in right-left mode. I'm guessing that this is a bug.

Sounds like it.

--
BLACK KNIGHT: I move for no man.
ARTHUR: So be it!
[hah] [parry thrust]
[ARTHUR chops the BLACK KNIGHT's left arm off]
ARTHUR: Now stand aside, worthy adversary.
BLACK KNIGHT: 'Tis but a scratch.
The Quest for the Holy Grail (Monty Python)

Paul Ruane

unread,
Jan 30, 2013, 8:36:01 AM1/30/13
to vim...@googlegroups.com
Fantastic, thanks guys.

Axel Bender

unread,
Jan 30, 2013, 9:28:19 AM1/30/13
to vim...@googlegroups.com
I think the current line number (rnu) should be idented like the rest (even if LineNr should be identical to CursorLineNr). Right now it looks a little bit ragged on the left side. What speaks against right-aligning the current line number?

Charles E Campbell

unread,
Jan 31, 2013, 7:42:31 PM1/31/13
to vim...@googlegroups.com
Ben Fritz wrote:
> I only rarely edit files with 10000 or more lines. Most of the time for me, my 'rnu' column takes 4 columns, and my 'nu' column takes 5. I don't care about the extra width, and would probably never turn off the option to show the absolute number on the current line if there were such an option. I'd support doing it that way always, but I'd accept an option as well.
>
When some users of some simulation s/w I helped write have a problem, I
usually end up with 10-150G long debugging traces; I usually break these
up into 1G chunks and "edit" (more usually, examine) these. So I often
end up with files having considerably more than 10,000 lines in them.
Since the patch has been accepted which installs the current line
number, I'll probably just use my RltvNmbr plugin instead.

Regards,
Chip Campbell

François Ingelrest

unread,
Feb 1, 2013, 2:56:17 AM2/1/13
to vim...@googlegroups.com
On Wed, Jan 30, 2013 at 12:31 PM, Bram Moolenaar wrote:
> This looks like a good solution. I'll include it. With Christian's
> addition.

I think I found a case where the 'relativenumber' option is reset. I'm
sending this report in this thread, although I don't know if it's
caused by the recent changes to relativenumber:

1. vim -u NONE -U NONE
2. :set number
3. :set relativenumber
4: :e .zshrc
5: :e .zsh_history

At step 4., relativenumber is on. At step 5., it's off. Not setting
number (step 3.) before relativenumber doesn't exhibit this behavior.

This is with Vim 7.3.798, features=big, on a Debian Squeeze.

Christian Brabandt

unread,
Feb 1, 2013, 3:37:26 AM2/1/13
to vim...@googlegroups.com
Hi Fran�ois!
Here is a patch.

regards,
Christian
set_nu_rnu.diff

Nazri Ramliy

unread,
Feb 1, 2013, 6:18:54 AM2/1/13
to vim...@googlegroups.com
On Fri, Feb 1, 2013 at 8:42 AM, Charles E Campbell
<drc...@campbellfamily.biz> wrote:
> When some users of some simulation s/w I helped write have a problem, I
> usually end up with 10-150G long debugging traces; I usually break these up
> into 1G chunks and "edit" (more usually, examine) these. So I often end up
> with files having considerably more than 10,000 lines in them. Since the
> patch has been accepted which installs the current line number, I'll
> probably just use my RltvNmbr plugin instead.

I can understand the problem. But hey this vim, the editor that lets you
customize a thousand things with its myriad of options, so here's a toy
patch that attempts to combine the number/relative number option into
a single option called 'linenumber'. Here's the relevant part in
options.txt:

-->8--
'linenumber' 'lnr' string (default "none")
local to window
{not in Vi}
Controls how line numbers are shown:
value effect
none No line numbers are shown
number Same as ":set number"
relative Same as ":set relativenumber"
numrel Same as ":set relativenumber", but instead of
showing '0' for the current line, show the actual
line number instead. The actual line number is
left-aligned to differentiate it from the relative
line number.
--8<--

The patch do not include Christian's fix for the problem
reported by François Ingelrest.

Nazri
lnr.diff

David Fishburn

unread,
Feb 1, 2013, 8:06:39 AM2/1/13
to vim_dev
I am in this exact situation:

wc -l xaa2.sql
19,461,476 xaa2.sql

I think the patch should be "smart" enough.
If the current line number exceeds available space, simply put a 0.
If it will fit in the space alloted, put the current line number.

Maybe it already does this?

My 2 cents.
David
 

Bram Moolenaar

unread,
Feb 1, 2013, 2:56:07 PM2/1/13
to Christian Brabandt, vim...@googlegroups.com

Christian Brabandt wrote:

> Hi François!
Thanks. Looks a bit tricky, perhaps we should have a test for this?
Won't be all that easy, I suppose.

--
When I look deep into your eyes, I see JPEG artifacts.
I can tell by the pixels that we're wrong for each other. (xkcd)

Christian Brabandt

unread,
Feb 2, 2013, 3:40:21 PM2/2/13
to vim...@googlegroups.com
Hi Bram!

On Fr, 01 Feb 2013, Bram Moolenaar wrote:

>
> Christian Brabandt wrote:
>
> > Hi Fran�ois!
> >
> > On Fr, 01 Feb 2013, Fran�ois Ingelrest wrote:
> >
> > > On Wed, Jan 30, 2013 at 12:31 PM, Bram Moolenaar wrote:
> > > > This looks like a good solution. I'll include it. With Christian's
> > > > addition.
> > >
> > > I think I found a case where the 'relativenumber' option is reset. I'm
> > > sending this report in this thread, although I don't know if it's
> > > caused by the recent changes to relativenumber:
> > >
> > > 1. vim -u NONE -U NONE
> > > 2. :set number
> > > 3. :set relativenumber
> > > 4: :e .zshrc
> > > 5: :e .zsh_history
> > >
> > > At step 4., relativenumber is on. At step 5., it's off. Not setting
> > > number (step 3.) before relativenumber doesn't exhibit this behavior.
> > >
> > > This is with Vim 7.3.798, features=big, on a Debian Squeeze.
> >
> > Here is a patch.
>
> Thanks. Looks a bit tricky, perhaps we should have a test for this?
> Won't be all that easy, I suppose.

No problem.

Mit freundlichen Gr��en
Christian
--
Bewunderung ist eine sehr kurzlebige Leidenschaft, die sofort
verf�llt, sobald man mit ihrem Gegenstand n�her bekannt wird.
-- Joseph Addison
relativenumber_bug.diff

Bram Moolenaar

unread,
Feb 3, 2013, 7:48:12 AM2/3/13
to Christian Brabandt, vim...@googlegroups.com

Christian Brabandt wrote:

> Hi Bram!
>
> On Fr, 01 Feb 2013, Bram Moolenaar wrote:
>
> >
> > Christian Brabandt wrote:
> >
> > > Hi François!
> > >
> > > On Fr, 01 Feb 2013, François Ingelrest wrote:
> > >
> > > > On Wed, Jan 30, 2013 at 12:31 PM, Bram Moolenaar wrote:
> > > > > This looks like a good solution. I'll include it. With Christian's
> > > > > addition.
> > > >
> > > > I think I found a case where the 'relativenumber' option is reset. I'm
> > > > sending this report in this thread, although I don't know if it's
> > > > caused by the recent changes to relativenumber:
> > > >
> > > > 1. vim -u NONE -U NONE
> > > > 2. :set number
> > > > 3. :set relativenumber
> > > > 4: :e .zshrc
> > > > 5: :e .zsh_history
> > > >
> > > > At step 4., relativenumber is on. At step 5., it's off. Not setting
> > > > number (step 3.) before relativenumber doesn't exhibit this behavior.
> > > >
> > > > This is with Vim 7.3.798, features=big, on a Debian Squeeze.
> > >
> > > Here is a patch.
> >
> > Thanks. Looks a bit tricky, perhaps we should have a test for this?
> > Won't be all that easy, I suppose.
>
> No problem.

Wonderful.


--
TIM: To the north there lies a cave, the cave of Caerbannog, wherein, carved
in mystic runes, upon the very living rock, the last words of Olfin
Bedwere of Rheged make plain the last resting place of the most Holy
Grail.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

Nazri Ramliy

unread,
Feb 3, 2013, 11:43:19 AM2/3/13
to vim...@googlegroups.com
On Fri, Feb 1, 2013 at 7:18 PM, Nazri Ramliy <ayie...@gmail.com> wrote:
> The patch do not include Christian's fix for the problem
> reported by François Ingelrest.

Attached is the updated (and less buggy) toy patch that include
Christian's fix and test89, and also test90 for testing the
new option 'linenumber'.

What the patch does is mirror the options 'number' and
'relativenumber' into a single option 'linenumber', which is
a string option.

To avoid expensive strcmps when checking for the value 'linenumber'
when drawing the line numbers I mirror it using an integer
option 'linenumberstyle' (w_p_lnrsty).

On one hand the patch simplifies tests like this:

i = (wp->w_p_nu || wp->w_p_rnu) ? number_width(wp) : 0;

to:

i = (wp->w_p_lnrsty != LNR_NONE) ? number_width(wp) : 0;

but on the other hand it seems to complicate things by
having multiple variables representing the same stuff :-/

Hence I'm still calling it a toy patch.

Nazri
lnr.diff

Charles Campbell

unread,
Feb 4, 2013, 9:22:09 AM2/4/13
to vim...@googlegroups.com
Nazri Ramliy wrote:
> On Fri, Feb 1, 2013 at 7:18 PM, Nazri Ramliy <ayie...@gmail.com> wrote:
>> The patch do not include Christian's fix for the problem
>> reported by Fran�ois Ingelrest.
> Attached is the updated (and less buggy) toy patch that include
> Christian's fix and test89, and also test90 for testing the
> new option 'linenumber'.
>
> What the patch does is mirror the options 'number' and
> 'relativenumber' into a single option 'linenumber', which is
> a string option.
>
> To avoid expensive strcmps when checking for the value 'linenumber'
> when drawing the line numbers I mirror it using an integer
> option 'linenumberstyle' (w_p_lnrsty).
>
> On one hand the patch simplifies tests like this:
>
> i = (wp->w_p_nu || wp->w_p_rnu) ? number_width(wp) : 0;
>
> to:
>
> i = (wp->w_p_lnrsty != LNR_NONE) ? number_width(wp) : 0;
>
> but on the other hand it seems to complicate things by
> having multiple variables representing the same stuff :-/
>
> Hence I'm still calling it a toy patch.

Thank you -- I'll try it out (but I'm having troubles getting gtk
enabled for vim for some odd reason, and am working on that)

Regards,
Chip Campbell


John Little

unread,
Feb 4, 2013, 10:23:56 PM2/4/13
to vim...@googlegroups.com, charles.e...@nasa.gov
On Tuesday, February 5, 2013 3:22:09 AM UTC+13, Charles Campbell wrote:

> Thank you -- I'll try it out (but I'm having troubles getting gtk
> enabled for vim for some odd reason, and am working on that)

Just in case you haven't, you've tried yum-builddep? (I mucked about for a while before discovering apt-get build-dep, and judging by how often I posted about it here so did others.)

Regards, John Little

Nazri Ramliy

unread,
Feb 5, 2013, 4:11:34 AM2/5/13
to vim...@googlegroups.com
Attached is an updated patch for the 'linenumber' option (it's getting
hairier and hairier! But not that much. I'd say it's less toy-ish by
now :)

It contains a bugfix - "set (inv|no)(nu|rnu)" did not correctly set
'linenumber' as well.

Earlier in the thread someone complained about the alignment of the
actual number compared to the relative number. I've added one more
option value to 'linenumber' to address this:

'linenumber' 'lnr' string (default "none")
local to window
{not in Vi}
Controls how line numbers are shown:
value effect ~
none No line numbers are shown
number Same as ":set number"
relative Same as ":set relativenumber"
numrel Same as ":set relativenumber", but instead of
showing '0' for the current line, show the actual
line number instead. The actual line number is
left-aligned to differentiate it from the relative
line number.
numrelaligned Same as ":set linenumber=numrel", but keep the
actual and relative line numbers aligned to the same
side.

I think this should cater for everyone - people who prefer relative
number but doesn't like color but still want to differentiate the
actual number - so they set lnr to 'numrel', and people who doesn't
like jagged line numbers so they set lnr to 'numrelaligned'.

On a different matter:

While working on this I noticed another bug, found in vanilla vim
changeset: 4089:30b3b1da0350:

$ src/vim -u NONE -U NONE src/misc1.c -c 'set nu|for i in
range(5)|split|endfor'
:" Now we should have 6 windows for src/misc1.c, go to the bottom window
:5wincmd j
:" Go to the last line in the window
:normal L
:windo set nu?
number
number
10808 }
number
number
number
Press ENTER or type command to continue

And notice that one or two of the output of "windo set nu?" includes
some text from the buffer.

Nazri
lnr.diff

Nazri Ramliy

unread,
Feb 5, 2013, 11:02:32 AM2/5/13
to vim...@googlegroups.com
On Tue, Feb 5, 2013 at 5:11 PM, Nazri Ramliy <ayie...@gmail.com> wrote:
> Attached is an updated patch for the 'linenumber' option (it's getting
> hairier and hairier! But not that much. I'd say it's less toy-ish by
> now :)
>
> It contains a bugfix - "set (inv|no)(nu|rnu)" did not correctly set
> 'linenumber' as well.

Another update for two more bugfixes for 'linenumber':

1. :mksession crashes vim due to the presence of the new, unnecessary
entry in options array for the hidden window local option w_o_lnrsty.
Removing the entry from options array solves it.
2. :mksession may set 'number' and/or 'relativenumber' after 'linenumber'
which will overwrite its setting. Solution: add the flag P_PRI_MKRC
to 'number' and 'relativenumber' options to ensure that they get
written first before 'linenumber'.

Nazri
lnr.diff

Lech Lorens

unread,
Feb 5, 2013, 11:22:59 AM2/5/13
to vim...@googlegroups.com
Would it be a good idea to deprecate 'number' and 'relativenumber' if
'linenumber' is introduced?
Could it be done by first introducing a warning "This setting will be
removed from future versions of Vim, please use 'linenumber' instead."
when 'nu' or 'rnu' is set and after some time actually removing the
settings? I can imagine that handling 'nu', 'rnu' and 'linenumber'
with their priorities in code is a huge PITA and a great possibility
of introducing bugs like the one you just fixed.

--
Cheers,
Lech
Message has been deleted
Message has been deleted

Ben Fritz

unread,
Feb 5, 2013, 1:56:53 PM2/5/13
to vim...@googlegroups.com
On Tuesday, February 5, 2013 10:22:59 AM UTC-6, Lech Lorens wrote:
> On 5 February 2013 17:02, Nazri Ramliy <ayie...@gmail.com> wrote:
>
> > On Tue, Feb 5, 2013 at 5:11 PM, Nazri Ramliy <ayie...@gmail.com> wrote:
>
> >> Attached is an updated patch for the 'linenumber' option (it's getting
>
> >> hairier and hairier! But not that much. I'd say it's less toy-ish by
>
> >> now :)
>
> >>
>
> >> It contains a bugfix - "set (inv|no)(nu|rnu)" did not correctly set
>
> >> 'linenumber' as well.
>
> >
>
> > Another update for two more bugfixes for 'linenumber':
>
> >
>
> > 1. :mksession crashes vim due to the presence of the new, unnecessary
>
> > entry in options array for the hidden window local option w_o_lnrsty.
>
> > Removing the entry from options array solves it.
>
> > 2. :mksession may set 'number' and/or 'relativenumber' after 'linenumber'
>
> > which will overwrite its setting. Solution: add the flag P_PRI_MKRC
>
> > to 'number' and 'relativenumber' options to ensure that they get
>
> > written first before 'linenumber'.
>
> >
>
> > Nazri
>
> >
>
>
>
> Would it be a good idea to deprecate 'number' and 'relativenumber' if
>
> 'linenumber' is introduced?
>

That would be a huge backwards incompatibility. I haven't followed the patches themselves closely, so maybe this is done already, but why can't setting 'number' and 'relativenumber' just have the effect of manipulating the 'linenumber' option (and vice versa)?

Ben Fritz

unread,
Feb 5, 2013, 1:58:48 PM2/5/13
to vim...@googlegroups.com
On Tuesday, February 5, 2013 12:56:53 PM UTC-6, Ben Fritz wrote:
> >
> >
> > Would it be a good idea to deprecate 'number' and 'relativenumber' if
> >
> > 'linenumber' is introduced?
> >
>
> That would be a huge backwards incompatibility. I haven't followed the patches themselves closely, so maybe this is done already, but why can't setting 'number' and 'relativenumber' just have the effect of manipulating the 'linenumber' option (and vice versa)?

For example:

:set number
:set relativenumber
:set linenumber=number
:set number? relativenumber? linenumber?
number norelativenumber linenumber=number

:set number
:set linenumber=number
:set relativenumber
:set number? relativenumber? linenumber?
nonumber relativenumber linenumber=relative

Christian Brabandt

unread,
Feb 5, 2013, 2:52:11 PM2/5/13
to vim...@googlegroups.com
Hi Nazri!

On Di, 05 Feb 2013, Nazri Ramliy wrote:

> While working on this I noticed another bug, found in vanilla vim
> changeset: 4089:30b3b1da0350:
>
> $ src/vim -u NONE -U NONE src/misc1.c -c 'set nu|for i in
> range(5)|split|endfor'
> :" Now we should have 6 windows for src/misc1.c, go to the bottom window
> :5wincmd j
> :" Go to the last line in the window
> :normal L
> :windo set nu?
> number
> number
> 10808 }
> number
> number
> number
> Press ENTER or type command to continue
>
> And notice that one or two of the output of "windo set nu?" includes
> some text from the buffer.

Also, the numbering is wrong after :windo executes and it this is really
strange, I noticed the cursor is displayed wrong in the last window and
even a :redraw! does not correct it. For me it is displayed in the 2nd
line, while :line('.') outputs :1

This patch fixes it:

diff --git a/src/window.c b/src/window.c
--- a/src/window.c
+++ b/src/window.c
@@ -3962,10 +3962,6 @@
win_goto(wp)
win_T *wp;
{
-#ifdef FEAT_CONCEAL
- win_T *owp = curwin;
-#endif
-
if (text_locked())
{
beep_flush();
@@ -3988,13 +3984,6 @@
need_mouse_correct = TRUE;
#endif
win_enter(wp, TRUE);
-
-#ifdef FEAT_CONCEAL
- /* Conceal cursor line in previous window, unconceal in current window. */
- if (win_valid(owp))
- update_single_line(owp, owp->w_cursor.lnum);
- update_single_line(curwin, curwin->w_cursor.lnum);
-#endif
}

#if defined(FEAT_PERL) || defined(PROTO)


I don't know, why Vim needs to redraw the cursor-line when executing the
windo command and I think it will redraw afterwards anyways, so it
should be safe to remove those lines.


regards,
Christian
--
Es gibt Leute, die nur aus dem Grunde in jeder Suppe ein Haar finden,
weil sie, wenn sie davor sitzen, so lange den Kopf sch�tteln, bis eins
hineinf�llt.
-- Christian Friedrich Hebbel

Nazri Ramliy

unread,
Feb 6, 2013, 3:08:07 AM2/6/13
to vim...@googlegroups.com
On Wed, Feb 6, 2013 at 2:58 AM, Ben Fritz <fritzo...@gmail.com> wrote:
> For example:
>
> :set number
> :set relativenumber
> :set linenumber=number
> :set number? relativenumber? linenumber?
> number norelativenumber linenumber=number

Yes, this is what the patch does. See the set_line_number_style() in
the patch. This is also how the test is done in test90.in, although I
would like to have another test that actually grabs vim's screen dump
and compare it with a known, correct text so that we can catch screen
drawing errors too ... maybe in another patch.

On Wed, Feb 6, 2013 at 12:22 AM, Lech Lorens <lech....@gmail.com> wrote:
> I can imagine that handling 'nu', 'rnu' and 'linenumber' with their
> priorities in code is a huge PITA and a great possibility of
> introducing bugs like the one you just fixed.

:) That PITA were present back when the useful 'rnu' were added:

$ grep 'w_p_nu.*w_p_rnu' src/*.c
src/edit.c: if (curwin->w_p_nu || curwin->w_p_rnu)
src/move.c: return (((wp->w_p_nu || wp->w_p_rnu) ? number_width(wp) + 1 : 0)
src/move.c: if ((wp->w_p_nu || wp->w_p_rnu) && vim_strchr(p_cpo,
CPO_NUMCOL) != NULL)
src/netbeans.c: - ((curwin->w_p_nu ||
curwin->w_p_rnu) ? 9 : 1);
src/screen.c: && curwin->w_nrwidth != ((curwin->w_p_nu ||
curwin->w_p_rnu)
src/screen.c: i = (wp->w_p_nu || wp->w_p_rnu) ? number_width(wp) : 0;
src/screen.c: if (wp->w_p_nu || wp->w_p_rnu)
src/screen.c: if ((wp->w_p_nu || wp->w_p_rnu)

The 'linenumber' patch adds a "hidden" window option (w_p_lnrsty) that
is controlled by the three "visible" window options 'number' (w_p_nu),
'relativenumber' (w_p_rnu) and 'linenumber' (w_p_lnr).

In the patch I've modified the code to use w_p_lnr in places where the
original w_p_nu/w_p_rnu options were directly affecting how the line
numbers are drawn, and ignoring the other places where they are used
in order to keep the patch size small and reduce the "affected area".

Here's the same grep output after the patch is applied:

$ grep 'w_p_nu.*w_p_rnu' src/*.c
src/move.c: return (((wp->w_p_nu || wp->w_p_rnu) ? number_width(wp) + 1 : 0)
src/move.c: if ((wp->w_p_nu || wp->w_p_rnu) && vim_strchr(p_cpo,
CPO_NUMCOL) != NULL)
src/netbeans.c: - ((curwin->w_p_nu ||
curwin->w_p_rnu) ? 9 : 1);
src/option.c: if (! curwin->w_p_nu && ! curwin->w_p_rnu)

If bram accepts the proposed patch then changing the rest of the
references to w_p_nu and w_p_rnu to use only w_p_lnrsty is trivial.

What makes me a bit uncomfortable is that there's so much code being
added just for styling how a single line number is shown when 'rnu' is
set, YAO and all :) Since this is something at affect stuff that people
see all day - we're talking programmers here and we know what line numbers
mean to us, some stare at it all day long - so it must be worth it yeah?

Nazri

Bram Moolenaar

unread,
Feb 6, 2013, 7:38:17 AM2/6/13
to Christian Brabandt, vim...@googlegroups.com
[...]

> I don't know, why Vim needs to redraw the cursor-line when executing the
> windo command and I think it will redraw afterwards anyways, so it
> should be safe to remove those lines.

The updating is needed, depending on 'concealcursor'.
But at least we can skip it when 'conceallevel' is zero.

It would still be wrong when conceal is on, thus more changes are
required. I think we should check if the screen is scrolled.

I'll make a patch, please try to find situations where it might still be
wrong.

--
Veni, Vidi, VW -- I came, I saw, I drove around in a little car.

Bram Moolenaar

unread,
Feb 6, 2013, 10:06:01 AM2/6/13
to Lech Lorens, vim...@googlegroups.com
No, I don't want to remove or deprecate existing options. It's very
annoying for people who get a new Vim version, especially if they didn't
install it themselves.

I'm not sure the whole 'linenumber' option thing is the right way to go.
We do not need to offer every possible way a user wants to see line
numbers.

--
LAUNCELOT: Isn't there a St. Aaaaarrrrrrggghhh's in Cornwall?
ARTHUR: No, that's Saint Ives.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

Charles Campbell

unread,
Feb 6, 2013, 11:05:35 AM2/6/13
to vim...@googlegroups.com
A use case:

A lot of people have downloaded LargeFile.vim to help them handle large
files (ie. not just me). I'd like some way to allow users of
LargeFile.vim to use relative numbering without a huge gutter for numbering.

Regards,
Chip Campbell

tooth pik

unread,
May 24, 2013, 5:00:29 PM5/24/13
to vim...@googlegroups.com
On Fri, May 24, 2013 at 12:22:44PM -0700, Dmitry Gorbik wrote:
> Sorry, but think this change without keeping an original behavior
> may just be too fast. Consider a workflow when you deal with files
> with a lot if lines. This is not too great for the line gutter to
> take a lot of space. This is actually why I use relative numbers -
> useful and doesn't take much space. I hope you will consider this
> case, Thanks

I too dislike this feature -- could we maybe have an option to get the
zero back?

--
_|_ _ __|_|_ ._ o|
|_(_)(_)|_| ||_)||<
|
Message has been deleted

Dmitry Gorbik

unread,
May 24, 2013, 11:12:30 PM5/24/13
to vim...@googlegroups.com

I just thought that it will have a huge psychological effect. Right now the brain is adjusted to the way numbers go from 0. Seeing some arbitrary number right near your code is not the best thing. Bram says it's annoying for people when we mess with existing settings, isn't this one of them? A lot of people who use relative number at the moment are used to check the current line number in the status bar. Moving this to another place breaks people habits. Yes, they will still be able to use status bar for that, but they get some distractive information.

Nazri Ramliy

unread,
May 30, 2013, 2:31:11 AM5/30/13
to vim_dev
On Wed, Feb 6, 2013 at 11:06 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:
> No, I don't want to remove or deprecate existing options. It's very
> annoying for people who get a new Vim version, especially if they didn't
> install it themselves.
>
> I'm not sure the whole 'linenumber' option thing is the right way to go.
> We do not need to offer every possible way a user wants to see line
> numbers.

The 'linenumber' patch adds too much code for controlling how the
current line number is shown when relative number is set.

Lane East's approach (earlier in this thread, rnucurrent.diff) is much
better and less intrusive but the proposed solution is flawed - it uses
a global variable for holding the option instead of window-local.

Attached is a patch based on Lane East's idea. I changed the option name
from "relativenumbercurrent" to the shorter "currentnumber":

Excerpt from ":help currentnumber":
--8<--
'currentnumber' 'cnu'
'currentnumber' 'cnu' number (default 0)
local to window
{not in Vi}
When 'relativenumber' is set, this option controls how the current line
number is shown:
value effect
-1 Show current line number, left aligned
0 Show 0 instead of current line number
1 Show current line number, right aligned
When 'relativenumber' is not set, this option has no effect.
-->8--

Several people have raised their unhappiness at how the new behavior of
'relativenumber' using a lot of screen columns for showing the current
line number for large files. The proposed 'currentnumber' option should
make everyone happy.

nazri
currentnumber.patch

Ben Fritz

unread,
May 30, 2013, 10:56:23 AM5/30/13
to vim...@googlegroups.com


See also the thread on vim_use with an alternate approach:

https://groups.google.com/d/topic/vim_use/fjG8gaeqpRc/discussion

IIUC the patch by Christian in that thread uses 'number' plus 'relativenumber' together to mean the same as 'currentnumber' set to 1 (or maybe -1), and 'relativenumber' by itself to mean 0.

tooth pik

unread,
May 30, 2013, 11:53:02 AM5/30/13
to vim...@googlegroups.com
it would certainly make me happy

sxc...@g.rit.edu

unread,
Jun 25, 2013, 1:56:01 PM6/25/13
to vim...@googlegroups.com

Is there any movement with this patch? What are Bram's thoughts on it?

I'm finding that the relativenumber changes are breaking the an old and fairly well-known method toggling relative and absolute numbers as configured here: http://www.vimbits.com/bits/192 . While I like this feature, I do agree having an option to default to the "old" behavior is best moving forward.

Thanks,
Stan

Ben Fritz

unread,
Jun 25, 2013, 2:10:38 PM6/25/13
to vim...@googlegroups.com
On Tuesday, June 25, 2013 12:56:01 PM UTC-5, sxc...@g.rit.edu wrote:
>
> Is there any movement with this patch? What are Bram's thoughts on it?
>

Bram's thoughts were that he doesn't want any new option for this.

But patch 7.3.1115 changes the 'number' and 'relativenumber' options so that instead of resetting each other, they interact with each other, so that 4 different displays can be achieved:

both set: relative numbers + absolute number in current line
relativenumber only: only relative numbers, 0 in current line
number only: only absolute numbers
neither set: no line numbering

> I'm finding that the relativenumber changes are breaking the an old and fairly well-known method toggling relative and absolute numbers as configured here: http://www.vimbits.com/bits/192 .

Then fix it. It can no longer rely on the old behavior where one option resets the other, since the options were modified to interact with each other instead.

If you like the absolute number in the current line, then you don't need to touch 'number' at all, just toggle relativenumber on and off.

If you do NOT like the absolute number in the current line, you need to do "set number norelativenumber" and "set nonumber relativenumber" instead of just setting one option or the other.

Christian Brabandt

unread,
Jun 25, 2013, 2:16:06 PM6/25/13
to vim...@googlegroups.com
Hi sxc4244!
A similar patch was integrated, which does not need a new option but
depends on how both options 'number' and 'relativenumber' work:
https://groups.google.com/d/msg/vim_dev/VBKxaoILi0s/l9o-OHv3vtkJ

regards,
Christian
--
Das Herz vor Freude schneller puckert, wenn man die Fr�hst�ckseier zuckert.

sxc...@g.rit.edu

unread,
Jun 29, 2013, 9:32:41 PM6/29/13
to vim...@googlegroups.com
Ah, I understand now; sorry for the confusion -- I didn't know that patch 1115 changed the behavior of relativenumber/number. I know what I have to do now to modify my vimrc to behave like it used to for older versions by using the has("patch#") check.

I do indeed like this new behavior better though :)
Thanks very much for your help!

--Stan

Reply all
Reply to author
Forward
0 new messages