[proposal] new 'cursorlinenr' option

[Ozaki Kiichi]

Hi.

I propose a new option 'cursorlinenr' to enable highlighting the line number of cursor.

[motive]

I think that the present spec, applying hl-CursorLineNr depends on 'cursorline' or 'relativenumber', isn't much convenient.

[spec]

'cursorlinenr' 'culn' boolean (default unset(-1))
local to window
Highlight the line number of the cursor with CursorLineNr
hl-CursorLineNr. Will make screen redrawing slower.
If this option is unset, highlighting depends on 'cursorline' or
'relativenumber'.

https://gist.github.com/ichizok/8d016c1e4c791499d092

Thank you.
- Ozaki Kiichi

[Ozaki Kiichi]

I updated the patch; add syntax.vim changes

https://gist.github.com/ichizok/8d016c1e4c791499d092

[Ozaki Kiichi]

I updated; changed type of 'cursorlinenr' to number.

https://gist.github.com/ichizok/8d016c1e4c791499d092

And added test.

https://gist.github.com/ichizok/aa54ecfe8aa7c94ce6711b940de16453

* which requires https://groups.google.com/forum/#!topic/vim_dev/tzNKP7EDWYI

[Gary Johnson]

On 2016-11-26, Ozaki Kiichi wrote:
> I updated; changed type of 'cursorlinenr' to number.
>
> https://gist.github.com/ichizok/8d016c1e4c791499d092

From your description, this option behaves like a boolean. Why
would you use the numerical values 1 and -1 instead?

Regards,
Gary

[Ozaki Kiichi]

> From your description, this option behaves like a boolean. Why
> would you use the numerical values 1 and -1 instead?

Sorry for lack of a description about 'cursorlinenr=0'. I have fixed it.

That is, 'cursorlinenr' is set to:

1: highlighting the line number
0: no highlighting
-1: highlighting depends on 'cursorline' or 'relativenumber'
(this is current behavior.)

In the previous patch, type of 'cursorlinenr' was boolean.
But it must set default value to other than 'on' and 'off', i.e. 'unset' (-1) for the
compatibility with current behavior, and I was not sure whether 'unset' can be
permitted.
(and changing value 'unset' to 'on' or 'off' is irreversible)

Thank you.

[Bram Moolenaar]

Using the magic numbers is hard to understand. New options are probably
better done with string values, such as "on", "off", and empty for not
set. Perhaps in this case "number", "line" and "both"? But then naming
it 'cursorlineopt' would be better.

--
"I can't complain, but sometimes I still do." (Joe Walsh)

/// 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 ///

[Gary Johnson]

On 2016-11-28, Bram Moolenaar wrote:
> Ozaki Kiichi wrote:
>
> > > From your description, this option behaves like a boolean. Why
> > > would you use the numerical values 1 and -1 instead?
> >
> > Sorry for lack of a description about 'cursorlinenr=0'. I have fixed it.
> >
> > That is, 'cursorlinenr' is set to:
> >
> > 1: highlighting the line number
> > 0: no highlighting
> > -1: highlighting depends on 'cursorline' or 'relativenumber'
> > (this is current behavior.)
> >
> > In the previous patch, type of 'cursorlinenr' was boolean.
> > But it must set default value to other than 'on' and 'off', i.e. 'unset' (-1) for the
> > compatibility with current behavior, and I was not sure whether 'unset' can be
> > permitted.
> > (and changing value 'unset' to 'on' or 'off' is irreversible)
>
> Using the magic numbers is hard to understand. New options are probably
> better done with string values, such as "on", "off", and empty for not
> set. Perhaps in this case "number", "line" and "both"? But then naming
> it 'cursorlineopt' would be better.

One has to remember, too, that if an option is a string and "global
or local to buffer", the only way (that I know of) to set the local
value to track the global value is to set the local value to empty.
Therefore, empty should not have any other special meaning. See
":help global-local".

Regards,
Gary

[Ozaki Kiichi]

> Using the magic numbers is hard to understand. New options are probably
> better done with string values, such as "on", "off", and empty for not
> set. Perhaps in this case "number", "line" and "both"? But then naming
> it 'cursorlineopt' would be better.

I have tried making out 'cursorlineopt' patch.

https://gist.github.com/ichizok/691aa7e848afd4aa8229c7a51aec895b

And test (also requires https://groups.google.com/forum/#!topic/vim_dev/tzNKP7EDWYI).

https://gist.github.com/ichizok/698abaef579911ec5157ba2be138739c

Thank you.

[Ozaki Kiichi]

I updated patches.

Change: test_cursorline.vim requires only view.vim of https://groups.google.com/forum/#!topic/vim_dev/tzNKP7EDWYI .

[Ozaki Kiichi]

https://github.com/vim/vim/pull/4693