From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alex Newsgroups: gmane.emacs.devel Subject: Re: Native line numbers, final testing Date: Tue, 04 Jul 2017 13:36:03 -0600 Message-ID: <87fuecc7vg.fsf@lylat> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1499196983 7670 195.159.176.226 (4 Jul 2017 19:36:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 4 Jul 2017 19:36:23 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 04 21:36:15 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 1dSTcK-0001Tq-PM for ged-emacs-devel@m.gmane.org; Tue, 04 Jul 2017 21:36:12 +0200 Original-Received: from localhost ([::1]:42751 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dSTcQ-0002K8-5d for ged-emacs-devel@m.gmane.org; Tue, 04 Jul 2017 15:36:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47458) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dSTcJ-0002K0-Aq for emacs-devel@gnu.org; Tue, 04 Jul 2017 15:36:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dSTcG-0005x3-6Q for emacs-devel@gnu.org; Tue, 04 Jul 2017 15:36:11 -0400 Original-Received: from mail-it0-x22f.google.com ([2607:f8b0:4001:c0b::22f]:36980) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dSTcF-0005wb-W2; Tue, 04 Jul 2017 15:36:08 -0400 Original-Received: by mail-it0-x22f.google.com with SMTP id m84so75950802ita.0; Tue, 04 Jul 2017 12:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version; bh=I0y79vp6QjwJOwkv7RrYvjm2cu/n2dPCERJ4GQViZWQ=; b=b23KUlJr05WF8fHHoal2+K00whRF1kGvzYc8dfSOJXGx8ut+ACBEkA/h/F9rmmJd9w A785n5bRD4RICz6n0OOOuXxr9qvvvpIqv0lrkL108uCd5KKZFSJZBh4GzHuffgW7ETZj 9cZemca9ZRcsUhnTKD1zMYWq9HZVpcX5WnHPR3cJAOBE9A2g+uKQFiFNkBLcAoNFwXqz vyGmh0H+eABxP8650CcebHQEp+xgDfmKwDQ7whFlMYTNcpHXD5M8F+Bx0VXggFdTnBjB slIDwGm1qQ5cTvVOo8ULXeFrBzwM4IRdinMbWe7Es8MZI3DqNfAZRRkibMy2BWBTHutC 8oQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references :user-agent:date:message-id:mime-version; bh=I0y79vp6QjwJOwkv7RrYvjm2cu/n2dPCERJ4GQViZWQ=; b=cBzKTOQftkNqi0Yk/F0D9ZWqQ1U6fpGswCpeQODii9Xj+VOzdkd63t6Yj3AUpIh6CI DV5R79Hnxluhkm+7o3aeljR+NN9FpaYfcgTDkvV57ZQvBMqyq5mqfaSgbk4cK3X8M/9o guxWr5CjThTwhctcALZb31pzgzEpii6xxdc/UOG6CNwQiCSKLvmOd8/ZU8KpUBsLIbmn sHpnctqWyfJe4bViCNeiElwJ3c12Mhra+KmsZBxfel3TDV75ufShUGz2D09Cocld0PfO oUma/XBC7reh9AIEn1eRPYufqgf9pXq7QKBtF4hZr5xvYjx4K/WTTWz+GLpiHsFXHcIC Gi/w== X-Gm-Message-State: AIVw112m1SyYYrP1hhrgcuUMykboR3eF6NDNtDaRuFWvJIYFysAWSEKQ yXV+WJFH0IT1RrPi X-Received: by 10.36.120.67 with SMTP id p64mr15738870itc.23.1499196966970; Tue, 04 Jul 2017 12:36:06 -0700 (PDT) Original-Received: from lylat (S010664777d9cebe3.ss.shawcable.net. [70.64.85.59]) by smtp.gmail.com with ESMTPSA id 137sm11814705itw.14.2017.07.04.12.36.05 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 04 Jul 2017 12:36:05 -0700 (PDT) In-Reply-To: <83wp7po86m.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 03 Jul 2017 18:24:01 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c0b::22f 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:216173 Archived-At: Eli Zaretskii writes: >> 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), 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. I highly doubt many, if anyone else, expect line numbers to behave like this. > but you will have a much harder time > convincing me to make a change in how scroll-preserve-screen-position > behaves in this case. Perhaps this one makes sense, since it is preserving screen position rather than column position. I'll wait and see if this part bothers me in the future. >> > 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? 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? >> 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)? >> 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? 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. Or would you provide a specific display-line-number hook? > P.S. Btw, I think these are all minor issues that shouldn't prevent > landing the feature on master. I believe that the C-n/C-p issue should at least be a blocker for 26.1.