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: Fri, 07 Jul 2017 09:19:54 +0300 Message-ID: <83a84gn4z9.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> <83y3s2n5pa.fsf@gnu.org> <878tk1rmjx.fsf@lylat> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1499408421 27975 195.159.176.226 (7 Jul 2017 06:20:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Jul 2017 06:20:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alex Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 07 08:20:17 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 1dTMci-0006vM-FK for ged-emacs-devel@m.gmane.org; Fri, 07 Jul 2017 08:20:16 +0200 Original-Received: from localhost ([::1]:54763 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dTMcm-000863-6Y for ged-emacs-devel@m.gmane.org; Fri, 07 Jul 2017 02:20:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45236) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dTMce-00084L-Bw for emacs-devel@gnu.org; Fri, 07 Jul 2017 02:20:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dTMcZ-0007oA-Cy for emacs-devel@gnu.org; Fri, 07 Jul 2017 02:20:12 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dTMcZ-0007nx-90; Fri, 07 Jul 2017 02:20:07 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4063 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dTMcY-0007J5-Ht; Fri, 07 Jul 2017 02:20:06 -0400 In-reply-to: <878tk1rmjx.fsf@lylat> (message from Alex on Thu, 06 Jul 2017 20:46:42 -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:216255 Archived-At: > From: Alex > Cc: emacs-devel@gnu.org > Date: Thu, 06 Jul 2017 20:46:42 -0600 > > Eli Zaretskii writes: > > >> 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. > > OK, so C-n/C-p currently try to preserve the column calculated by either > posn-col-row or posn-actual-col-row? More accurately, C-n/C-p try to preserve the horizontal coordinate (which can be expressed either in pixels or in canonical column units), and posn-col-row calculates and returns the same coordinates. > If one has to choose between these two behaviours, then I believe the > former is significantly more user-friendly. It is much easier to reason > about, and it does not change the horizontal cursor position relative to > buffer contents. OK. > Sorry, I think we both lost focus a bit since there's a few different > topics in this thread. Here, I believe we were talking about line > numbers in the margin, and if the property of being in the margin by > itself would be able to avoid this issue. I was under the assumption > that it would be, but assuming strict compliance to the documentation of > line-move-visual, then I think I get now why it wouldn't. Actually, I think it would be easier, because x coordinates are counted from the text-area edge, so they are unaffected by the margins. But this fact alone is not enough to invalidate the design that doesn't use the margin for line numbers. A few complications like the one we are talking about can always be solved by some support code, they are not obstacles that cannot be negotiated. > I figured it would be best to change display-line-number-width as soon > as possible, and for the check to be made as infrequent as possible. Line numbers are calculated every redisplay cycle (for those lines that need to be redrawn), and a redisplay cycle always follows a command, so the frequency is not affected by using the hooks I proposed. > pre-command-hook definitely sounds better than pre-redisplay-functions, > but it would be nice if the check didn't have to be made every time a > command is issued. Although I suppose if the width accessor is a fast > constant lookup, then it doesn't really matter. It cannot be an accessor to a value that is already stored (because it currently isn't stored anywhere once redisplay finishes), but it should be fast enough nonetheless. And if it turns out it isn't, we can always speed it up.