From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Native line numbers, final testing Date: Mon, 03 Jul 2017 18:24:01 +0300 Message-ID: <83wp7po86m.fsf@gnu.org> References: <83y3s9pm2a.fsf@gnu.org> <87vandz7lw.fsf@lylat> <83wp7tpcav.fsf@gnu.org> <87r2y1z45o.fsf@lylat> <83vandp7wz.fsf@gnu.org> <87mv8pyy7f.fsf@lylat> <83shigpoxq.fsf@gnu.org> <87mv8nkh31.fsf@lylat> <83bmp3pnmb.fsf@gnu.org> <87eftzju5g.fsf@lylat> <837ezqq3gd.fsf@gnu.org> <874luuyuqy.fsf@lylat> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1499095540 24868 195.159.176.226 (3 Jul 2017 15:25:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 3 Jul 2017 15:25:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alex Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 03 17:25: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 1dS3EA-0005qr-MK for ged-emacs-devel@m.gmane.org; Mon, 03 Jul 2017 17:25:30 +0200 Original-Received: from localhost ([::1]:35833 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dS3EE-00017U-H0 for ged-emacs-devel@m.gmane.org; Mon, 03 Jul 2017 11:25:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dS3Cs-0000m7-H6 for emacs-devel@gnu.org; Mon, 03 Jul 2017 11:24:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dS3Cp-0007VM-KA for emacs-devel@gnu.org; Mon, 03 Jul 2017 11:24:10 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59084) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dS3Cp-0007VC-Gs; Mon, 03 Jul 2017 11:24:07 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4906 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dS3Co-0008EB-Sh; Mon, 03 Jul 2017 11:24:07 -0400 In-reply-to: <874luuyuqy.fsf@lylat> (message from Alex on Sun, 02 Jul 2017 23:06:29 -0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:216137 Archived-At: > From: Alex > Cc: emacs-devel@gnu.org > Date: Sun, 02 Jul 2017 23:06:29 -0600 > > > I think I fixed that now. > > The issue is a bit harder to encounter now, but it appears to still be > present. In xdisp.c: > > M-g c 2970 RET > C-u 16 C-n > > Then hit C-n a few times to reach line 87. The cursor will now be on > column 26 instead of column 27. > > You can also test this by holding C-n or C-p and noticing the goal > column changing. This also affects C-v and M-v with > scroll-preserve-screen-position set to 'always. No, that's an entirely different issue, and arguably not a bug at all. In line-move-visual mode, C-n/C-p (and vertical-motion they call under the hood) keep the horizontal screen coordinate as much as they possibly can, and this is what happens here. You can see the same "bug" with this simple recipe: emacs -Q M-: (add-text-properties 72 73 '(line-prefix "12345")) RET C-u 10 M-g c C-= C-n C-= The last command will say "column=4" although you started with column=9. Maybe with C-n/C-p people will expect what you expected in the case of line numbers (but I'd like to hear more opinions before I'm convinced to change the code to do that), but you will have a much harder time convincing me to make a change in how scroll-preserve-screen-position behaves in this case. > > And note that displaying the numbers in the margin would not have > > solved the issue, since the width of the margins would still be > > estimated by the same heuristics. > > So there's no reliable way to get the x-coordinate of the end of the > left margin/fringe? Of course there is: call posn-at-point and its ilk. The problem is to know that x coordinate _before_ the margins actually change their width. That is the problem to be solved in this case. > Why don't these issues affect nlinum, since it sets > the width dynamically? Because nlinum and similar modes change the width of the margin _after_ C-n already moved point. So C-n does its thing with the margin still at its old width, and doesn't need to deal with the width changing under its feet. > On this note, I'd like to again ask for dynamic growing of the width, > but not shrinking. That should also help towards avoiding this problem > in growing buffers. > > I've edited and attached my previous proof of concept, but it uses > Fmake_local_variable, which doesn't look like it's used a lot in the C > side of Emacs. Is there a better way to make buffer local internal > variables? I don't think this should be done in C. I can provide a function to obtain the current width of the line-number display, and then a Lisp program, called from some suitable hook, could notice when the value becomes larger, and set display-line-number-width to that same value. Would that be satisfactory? P.S. Btw, I think these are all minor issues that shouldn't prevent landing the feature on master.