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: Sun, 02 Jul 2017 18:10:58 +0300 Message-ID: <837ezqq3gd.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1499008284 8205 195.159.176.226 (2 Jul 2017 15:11:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 2 Jul 2017 15:11:24 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alex Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 02 17:11:16 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 1dRgWn-0001da-Po for ged-emacs-devel@m.gmane.org; Sun, 02 Jul 2017 17:11:13 +0200 Original-Received: from localhost ([::1]:58339 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dRgWr-0005kr-ER for ged-emacs-devel@m.gmane.org; Sun, 02 Jul 2017 11:11:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42341) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dRgWk-0005km-OZ for emacs-devel@gnu.org; Sun, 02 Jul 2017 11:11:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dRgWh-0006uY-Kj for emacs-devel@gnu.org; Sun, 02 Jul 2017 11:11:10 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40668) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dRgWh-0006uS-Gi; Sun, 02 Jul 2017 11:11:07 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3781 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dRgWg-0007aE-PP; Sun, 02 Jul 2017 11:11:07 -0400 In-reply-to: <87eftzju5g.fsf@lylat> (message from Alex on Sat, 01 Jul 2017 23:16:11 -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:216108 Archived-At: > From: Alex > Cc: emacs-devel@gnu.org > Date: Sat, 01 Jul 2017 23:16:11 -0600 > > > Because vertical-motion thinks the display uses N+1 columns whereas it > > actually uses only N. > > > >> Is it because it's using the heuristic with different inputs? > > > > Yes. The important input is the actual window-start point. > > > >> If so, can't they be modified to achieve the same results as the > >> display of line numbers? > > > > I couldn't (yet) find a way of doing that. > > That's unfortunate; hopefully this can be fixed. I think I fixed that now. > > I firmly believe that line numbers should not be displayed on the > > margins, because that produces problems for packages that want to > > display stuff there. > > That seems to me to be an extensibility problem rather than line numbers > not belonging in the margins. Without fixing that problem, then there > will still be problems when multiple packages attempt to use the margins > simultaneously. That's correct, but since coexistence in the margin is problematic, core features, especially popular ones, should not use the margins, so as not to exacerbate the problems. 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. > Can there not be multiple margins on one side? No, not without a thorough redesign and rewrite of the display code. The fact that there's at most one margin on either side of the text area is hard-coded in many places. > That way, line numbers can have its own special area, and there will > be a clear x-coordinate for vertical-motion to start from, avoiding > a whole class of errors that you've had to deal with so far. See above: these problems won't be solved by going to the margin. The only way to solve them is to have a fixed width for line numbers, something that can be done, if desired, by suitable setting of display-line-number-width.