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 display of line numbers Date: Sun, 18 Jun 2017 22:00:29 +0300 Message-ID: <83k249xgs2.fsf@gnu.org> References: <83lgoqzm0v.fsf@gnu.org> <83tw3dxs60.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1497812485 7171 195.159.176.226 (18 Jun 2017 19:01:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 18 Jun 2017 19:01:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: Yuri Khan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 18 21:01:21 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 1dMfRp-0001Y6-81 for ged-emacs-devel@m.gmane.org; Sun, 18 Jun 2017 21:01:21 +0200 Original-Received: from localhost ([::1]:39286 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dMfRu-0005va-DD for ged-emacs-devel@m.gmane.org; Sun, 18 Jun 2017 15:01:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dMfRG-0005vP-HC for emacs-devel@gnu.org; Sun, 18 Jun 2017 15:00:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dMfRD-0002iy-GM for emacs-devel@gnu.org; Sun, 18 Jun 2017 15:00:46 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60105) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dMfRD-0002iu-Be; Sun, 18 Jun 2017 15:00:43 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3736 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dMfRC-00060q-NB; Sun, 18 Jun 2017 15:00:43 -0400 In-reply-to: (message from Yuri Khan on Sun, 18 Jun 2017 23:54:38 +0700) 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:215753 Archived-At: > From: Yuri Khan > Date: Sun, 18 Jun 2017 23:54:38 +0700 > Cc: Emacs developers > > > But I'm not sure I understand the motivation: is it due to the > > background issues with the margins? If so, fixing that might be much > > easier. > > The base motivation is to have an intuitive ordering of out-of-buffer > adornments. Out of the box in Emacs, there are: > > * line numbers > * line wrap indicators > * horizontal scrolling indicators > * debugging overlay arrows > > Some IDEs also display in their gutters: > > * change bars indicating modifications since the last commit (in > Emacs, see Git-Gutter) > * in-buffer bookmark indicators (functionality of bm.el) > * folding indicators and controls (functionality of outline-minor-mode) > * static analysis warnings (flycheck) > > Some of these attract to the buffer text more strongly than others. Yes, but why is that a problem? And if some combinations are really too much, then are those combinations really that frequent that they should be source of a worry? And if they are, how come this wasn't an issue until now? > « sit amet, consectetur wgah’nagl fhtagn. > > So far, in all cases, a scrolling indicator implies some text is > elided at this point. > > Now we enable line numbers. As is: > > « 42 amet, consectetur wgah’nagl fhtagn. > > If the elided text were inserted at the position of the indicator, the > line number would end up in the middle of the line. Compare: > > 42 «t amet, consectetur wgah’nagl fhtagn. OK, and what's your point? That the line number display is not ideal? I agree, but I think the alternatives are much worse. E.g., switching the order can only work on TTY frames and when the fringes are disabled, so it cannot be done by default, or we will have inconsistent behavior. I'm sure people who like line numbers will get used to the arrangement of indicators soon enough; I did. Especially since long lines are rare in source code buffers, at least IME. > If the margin background issue were fixed but line numbers remained > closely tied to the buffer, I would probably continue using the now > deprecated linum-mode, because this configuration gives me the > intuitive ordering. Experience shows that using the margins for such pervasive modes is trouble in itself, because there are modes which want to use the margins for their own purposes. We still don't have a satisfactory solution for those problems. Displaying the numbers in the text area solves them by simply keeping its hands off the margins. I think the gains here outweigh the minor disadvantages by a large margin (pun intended), so I'd rather pay those small "fines" to have a cleaner solution for margin usage, let alone a much faster redisplay (have you tried relative-line-numbers-mode in windows under Follow Mode?).