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: Wed, 05 Jul 2017 20:39:45 +0300 Message-ID: <83y3s2n5pa.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> <83wp7po86m.fsf@gnu.org> <87fuecc7vg.fsf@lylat> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1499276556 4494 195.159.176.226 (5 Jul 2017 17:42:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 5 Jul 2017 17:42:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alex Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 05 19:42:31 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 1dSoJq-0000nU-3E for ged-emacs-devel@m.gmane.org; Wed, 05 Jul 2017 19:42:30 +0200 Original-Received: from localhost ([::1]:47418 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dSoJv-0003UB-61 for ged-emacs-devel@m.gmane.org; Wed, 05 Jul 2017 13:42:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dSoHV-0000x1-3k for emacs-devel@gnu.org; Wed, 05 Jul 2017 13:40:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dSoHR-0008F6-UB for emacs-devel@gnu.org; Wed, 05 Jul 2017 13:40:05 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37181) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dSoHR-0008Ex-QR; Wed, 05 Jul 2017 13:40:01 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2864 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dSoHR-0008C4-5S; Wed, 05 Jul 2017 13:40:01 -0400 In-reply-to: <87fuecc7vg.fsf@lylat> (message from Alex on Tue, 04 Jul 2017 13:36:03 -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:216189 Archived-At: > From: Alex > Cc: emacs-devel@gnu.org > Date: Tue, 04 Jul 2017 13:36:03 -0600 > > I've never heard of line-prefix before this discussion, so I don't know > what the expected behaviour of it is/should be. However, I don't believe > the width of the line numbers should have any bearing on the column > position of a particular character in the buffer. Indeed, C-x = at the > beginning of a line with display-line-numbers correctly shows > "column=0". So I don't see the link between your recipe and mine. "C-x =" just counts characters. Try "M-: (posn-at-point) RET" for more insight. > I highly doubt many, if anyone else, expect line numbers to behave like > this. It's quite possible. I just want to hear that before I write the code. Since I probably won't use line numbers (except for debugging problems they cause ;-), I don't think my judgment is good enough here. > >> > 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. > > I don't understand. If the x-coordinate can be calculated at the start > of vertical-motion, then isn't that the x-coordinate before the margins > change their width? Yes. But I think we are talking past each other, see below. > As a thought for the current problem, could you adjust the position > after vertical-motion is called if it turns out that the > line-number-width/margin-size changed? Sure. I already write code to do that, I just stashed it waiting to see what this discussion concludes. (And it isn't enough to make the correction inside vertical-motion: temporary-goal-column also needs to be adjusted.) > >> 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. > > Didn't you write before (when talking about 'visual) that line number > calculation/display was done after the point is moved? In that case, how > is display-line-numbers different to what you just described (outside of > not using the margin)? I think I lost the focus of this discussion, so I'm not sure anymore I'm answering your questions correctly. What is it that you are getting at with these questions? > > 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? > > If the performance and convenience is about the same, then I suppose it > doesn't matter where it's implemented. What would be a suitable hook? I > see a pre-redisplay-functions, but not a post-redisplay-functions. pre-redisplay-functions should be OK, but I think even pre-command-hook is fine. You really want to set this before redisplay runs, because after it runs it might be too late. > would you provide a specific display-line-number hook? I don't see why we would want such a hook, and what would it do and how. > I believe that the C-n/C-p issue should at least be a blocker for 26.1. We should be well past this long before we consider what blocks 26.1.