From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Kaushal Modi Newsgroups: gmane.emacs.devel Subject: Re: Native display of line numbers Date: Sun, 18 Jun 2017 04:27:38 +0000 Message-ID: References: <83lgoqzm0v.fsf@gnu.org> <83injuzf4e.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c1cd16ce824f90552347042" X-Trace: blaine.gmane.org 1497760118 5121 195.159.176.226 (18 Jun 2017 04:28:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 18 Jun 2017 04:28:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 18 06:28:34 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMRpA-00011R-EF for ged-emacs-devel@m.gmane.org; Sun, 18 Jun 2017 06:28:32 +0200 Original-Received: from localhost ([::1]:37066 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dMRpF-0007lZ-PL for ged-emacs-devel@m.gmane.org; Sun, 18 Jun 2017 00:28:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54721) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dMRoZ-0007go-5d for emacs-devel@gnu.org; Sun, 18 Jun 2017 00:27:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dMRoX-0004c5-J4 for emacs-devel@gnu.org; Sun, 18 Jun 2017 00:27:55 -0400 Original-Received: from mail-lf0-x233.google.com ([2a00:1450:4010:c07::233]:36625) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dMRoV-0004bF-6M; Sun, 18 Jun 2017 00:27:51 -0400 Original-Received: by mail-lf0-x233.google.com with SMTP id o83so40706449lff.3; Sat, 17 Jun 2017 21:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3eQa0lEP4YC8Fz/PFmwjCQ0VVdXyhqLYLczRtWHKxg8=; b=gq1e605u7eFtT6JpMT92k1Sw+HKxqL7pnkLtqyq4dqn+aKQOHUZKBu8Ex4WGaTqs22 tJQ4QcLueEhumfWx6LqIgHFSuRV9h09+/x9ak7ZeYnhKjquL1fnJgzaHzHfX5hx6uEMc rY/Tc56BTOqzvCxre+QLSYYjK/cZOMMbjNHqv/w0sbnhBNCiP+6QpIrgGvNyikmx7JtG gh/So8T7OL/LaB3i8XSprfQlbfQOg1OxHVRv2HFPiNI9jIdlTxReNBtAkMhg7M6LOZFb YrkBvPfsW+a8MzjMykguqPj1csn8BpTPEt4WUS+JKFXwBwJRB+Prgsj5J5wkYVo1D9hu UvRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3eQa0lEP4YC8Fz/PFmwjCQ0VVdXyhqLYLczRtWHKxg8=; b=jjUXCiLl1qAlivX+ew7ioXe1y79t61nWUAmX51lCZdJNNMW16e6ScJCJ5/LOg5R797 bJMCxaeus1tNQiciNSmKRMNASoVatlkd3CGE7Yw3d7BRihTwZkTpcdFVNnqyh78IvIpj HRDaTsGKc/BBQjv2WtUvY6q5oNJZbJIZcK953B4JMggoiOrCndvrF8kWemTBbhcmziVF auQNpEB3IcaxzKbtK8BIbBLw3qWkCWBEhauTwasbvd5FZBwYMURKpVMROnQVz81fH3XT sQWeoUcjwFU6IHubHBoiBn80CBmt9J6NWGSpdiU4yJueefpdDBwv4VKA2ONA8CBOEZuG RYMg== X-Gm-Message-State: AKS2vOzRC4l0v0pRw53OeTsz6xJiLieuWvlTmsC8ihaFe5aonF4Ov95l ySxPYn98NE8/XvKhAxeuFsJZPNd8UQ== X-Received: by 10.46.21.22 with SMTP id s22mr5252666ljd.121.1497760069590; Sat, 17 Jun 2017 21:27:49 -0700 (PDT) In-Reply-To: <83injuzf4e.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::233 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:215732 Archived-At: --94eb2c1cd16ce824f90552347042 Content-Type: text/plain; charset="UTF-8" On Sat, Jun 17, 2017 at 1:41 PM Eli Zaretskii wrote: > 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 presence of packages like https://github.com/tom-tan/hlinum-mode, https://github.com/hlissner/emacs-nlinum-hl, and many people asking how to highlight the current line number on external emacs forums (like emacs.stackexchange.com or reddit.com/r/emacs) tells that many people would appreciate this feature. 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. On Sat, Jun 17, 2017 at 1:42 PM Eli Zaretskii wrote: > > 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. -- Kaushal Modi --94eb2c1cd16ce824f90552347042 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jun 17= , 2017 at 1:41 PM Eli Zaretskii <eliz@gn= u.org> wrote:
nlinum perform= ed so poorly in my benchmarks that I was ashamed of
publishing the data.=C2=A0 The benchmark entails scrolling through xdisp.c<= br> one line at a time.=C2=A0 The code is at the end of this message (it was posted by Dmitry Antipov), you can try it yourself.=C2=A0

Thanks. I haven't yet tried that. I do not work in C mo= st of the time and so may be I never noticed it. nlinum has been super smoo= th 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, an= d the current line highlighting feature for the past year.
=C2=A0=
Is it really important?=C2=A0 Why? do people really have difficulty finding=
the line where point/cursor is?

It redu= ces cognitive load in my experience. I need to refer to the line numbers mo= re frequently than some; I frequently do code reviews, discuss code change = with colleagues at remote locations. So with if my cursor is at the beginni= ng of a function definition, it's really quick to glance to the left, l= ook at the highlighted number, and tell the other people "jump to X li= ne", 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 glanc= e to tell the current line num is much faster than looking for the line num= ber in the mode line.
=C2=A0
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 shou= ld perform even better.=C2=A0

The presence of pack= ages like https://github= .com/tom-tan/hlinum-mode, https://github.com/hlissner/emacs-nlinum-hl, and many people= asking how to highlight the current line number on external emacs forums (= like emacs.stackexchange.com= or reddit.com/r/emacs) tells tha= t many people would appreciate this feature.=C2=A0

The menu bar is for simple uses, I see no reason= to put all the
complexity of a defcustom on the menu bar.

<= div>The toggle-display-line-numbers is an interactive function though. So s= omeone can unknowingly bind it to a key to toggle line numbers and get conf= used why their setting to show relative line numbers is getting lost. It al= so needs a doc-string saying that that function is only for use from the me= nu bar, and point the user to look at display-line-numbers var instead to d= o 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.
= =C2=A0
Minor mode is probably due anywa= y, but that is independent of the menu
bar.

Anyway, these are simple things that can always be fixed later.

Understood.
=C2=A0
Thanks for taking time to try the branch.
<= br>
Thanks for working on this.

On Sat, Jun 17, 2017 at 1:42 PM Eli Zaretskii <eliz@gnu.org> wrote:
> Can the same minor mode be reused? Then us= ing a defcustom user can specify:

I don't think we should do tha= t, because the other similar modes
didn't turn off line numbers in t= he mode line.

I didn't follow that. But= I also see that line-number-mode is a global minor mode. For this line num= bers feature, we need a mode that can be enabled just locally or globally.<= /div>

We definitely need a more intuitive minor mo= de name for this. If this feature is a superset of linum-mode, then may be = just call that.
--

Kaushal Modi

--94eb2c1cd16ce824f90552347042--