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: Thu, 06 Jul 2017 20:46:42 -0600 Message-ID: <878tk1rmjx.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> <87fuecc7vg.fsf@lylat> <83y3s2n5pa.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1499395631 8758 195.159.176.226 (7 Jul 2017 02:47:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Jul 2017 02:47:11 +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 Fri Jul 07 04:47:06 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 1dTJIP-0001zu-HX for ged-emacs-devel@m.gmane.org; Fri, 07 Jul 2017 04:47:05 +0200 Original-Received: from localhost ([::1]:54202 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dTJIU-0001XF-UQ for ged-emacs-devel@m.gmane.org; Thu, 06 Jul 2017 22:47:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46194) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dTJIN-0001Wl-LM for emacs-devel@gnu.org; Thu, 06 Jul 2017 22:47:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dTJII-0000my-OZ for emacs-devel@gnu.org; Thu, 06 Jul 2017 22:47:03 -0400 Original-Received: from mail-it0-x242.google.com ([2607:f8b0:4001:c0b::242]:34165) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dTJII-0000jy-JD; Thu, 06 Jul 2017 22:46:58 -0400 Original-Received: by mail-it0-x242.google.com with SMTP id o202so3452872itc.1; Thu, 06 Jul 2017 19:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=4CMsj1nj9qecpXylh4cILdPNwrTZVJHkBupWAVhQvbo=; b=Yr0cya4Hj44DGyp0KUF9sgOl9DWO2LSUTFMEzJe+gshi2T4J4UwkxWWWijEDjUBpFs ab1FkBZ7dmQ+XfTrOt2rKFnpv/MPbywUAZ8xGthp2xBWtSTugG4pUCv0/t0NqYl3Bpkt SYvCLutZL6iuvtLjsE0sIXiHl5H9i6xpl5HRUbxEW5SJ7aLn6ithF0rdHbQXy0eql7M/ UHG8eCSoBJofM3pZLH0HUUaM6LoZwWrjxBBbyT/OEPLmWlfT1HaPutj2vrd8jACHyu/T IBEg6+EuZ46ipUHJh2MGia7NUOk+VPAX6wE2epo0a5wmM5O4GffFiLAzZqi/lToix7tj uyzQ== 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:references:date:in-reply-to :message-id:user-agent:mime-version; bh=4CMsj1nj9qecpXylh4cILdPNwrTZVJHkBupWAVhQvbo=; b=aqDglMl1NbB994Jq2AgvsdhYmVkFLoSBDkXWheCm4DCqNDWsbZyIjG02kIgEHChNFE 4oU7E49tXir25zum43WkL4twOz/dkMSd9Fh8kM3AZn625rDPfDgRGwcpGPBQsjNsO8In UUrhz9cXMpdMYgvIjTSY/P1nmbxOPkhoR9xqGN/gOM76/J1x1QiD3qQ/EpOVATQudH9k VT3T9q2HBpYPn8yLO6Wu1ipPkKuhiexoDx1sKS28LBTw39U8f+bU5vTvemrjjpWIKOco Ez3L2YMWQ508kO+wp7N/ClbIvMNx/Mw29kjNSlTpl/oUJzsa6OQ4EAk1rm4STyPkSoMt FqxQ== X-Gm-Message-State: AIVw112wjK/IY/nfiVIS0D84z2rT1gaOriz1OTcO6E4HHfKJKcfJlpYW ZRWxBGPWt7QfaXLG X-Received: by 10.36.94.10 with SMTP id h10mr935168itb.103.1499395615896; Thu, 06 Jul 2017 19:46:55 -0700 (PDT) Original-Received: from lylat (S010664777d9cebe3.ss.shawcable.net. [70.64.85.59]) by smtp.gmail.com with ESMTPSA id f1sm1211377itc.13.2017.07.06.19.46.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 06 Jul 2017 19:46:54 -0700 (PDT) In-Reply-To: <83y3s2n5pa.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 05 Jul 2017 20:39:45 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c0b::242 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:216253 Archived-At: 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? I believe I understand now, though I still disagree that line numbers should behave similarly. It appears that both nlinum and display-line-numbers contradict the 2nd sentence of the documentation for line-move-visual. When the line number width in nlinum increases, everything including the cursor is shifted over. So if C-n triggers this change, then one could consider this to be wrong behaviour. In display-line-numbers, then C-n and C-p both may not preserve the current horizontal screen position even when the line number width does not (noticeably) change. Here, the horizontal screen position of the cursor is moved by 1 character, but in contrast to the nlinum case, the rest of the buffer contents remain horizontally stationary. 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. >> 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. I think a reasonable default is to behave similarly to the previous line number implementations where it makes sense, and to change it if users tend to dislike it. I suppose the contention here may be "where it makes sense". I think it makes sense for the basic navigation commands to behave similarly between the different implementations. >> 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.) It's good to know that there's a working solution. I hope it will land in Emacs. >> >> 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? 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. >> > 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 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. A hook called in the same area that it->lnum_width is changed would be the best for that, though perhaps that's going overboard. 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.