nlinum performed so poorly in my benchmarks that I was ashamed of
publishing the data. The benchmark entails scrolling through xdisp.c
one line at a time. The code is at the end of this message (it was
posted by Dmitry Antipov), you can try it yourself.
Thanks. I haven't yet tried that. I do not work in C most of the time and so may be I never noticed it. nlinum has been super smooth for me (with the current line highlight enabled too) for the major modes that I am working on. I have been using nlinum for many many years now, and the current line highlighting feature for the past year.
Is it really important? Why? do people really have difficulty finding
the line where point/cursor is?
It reduces cognitive load in my experience. I need to refer to the line numbers more frequently than some; I frequently do code reviews, discuss code change with colleagues at remote locations. So with if my cursor is at the beginning of a function definition, it's really quick to glance to the left, look at the highlighted number, and tell the other people "jump to X line", instead of asking them to search for a function name, etc. I can look in the mode line too to get the line number. But this quick left glance to tell the current line num is much faster than looking for the line number in the mode line.
I could add this feature if it's deemed important, but it will slow
down redisplay to some extent, because cursor motion can no longer be
considered affecting the cursor alone.
Even if this feature is enabled, I believe that it would have a defcustom. If nlinum with current line highlighting is working fine, I think this should perform even better.
The menu bar is for simple uses, I see no reason to put all the
complexity of a defcustom on the menu bar.
The toggle-display-line-numbers is an interactive function though. So someone can unknowingly bind it to a key to toggle line numbers and get confused why their setting to show relative line numbers is getting lost. It also needs a doc-string saying that that function is only for use from the menu bar, and point the user to look at display-line-numbers var instead to do what they want. Also if that function is intended to be called only from the menu bar, should it be prefixed with "menu-bar-"? It would go against the convention used in that file, but it adds clarity.
Minor mode is probably due anyway, but that is independent of the menu
bar.
Anyway, these are simple things that can always be fixed later.
Understood.
Thanks for taking time to try the branch.
Thanks for working on this.
> Can the same minor mode be reused? Then using a defcustom user can specify:
I don't think we should do that, because the other similar modes
didn't turn off line numbers in the mode line.
I didn't follow that. But I also see that line-number-mode is a global minor mode. For this line numbers feature, we need a mode that can be enabled just locally or globally.
We definitely need a more intuitive minor mode name for this. If this feature is a superset of linum-mode, then may be just call that.