From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Romanos Skiadas Newsgroups: gmane.emacs.bugs Subject: bug#28533: 26.0.60; Native line numbers move with show-paren-mode enabled Date: Sat, 23 Sep 2017 09:49:03 +0100 Message-ID: <429d60e7-7b38-aa85-679f-3aaff4424756@gmail.com> References: <821a99c1-2f86-a13b-31bb-06d7898fe9c3@gmail.com> <83wp4se7qp.fsf@gnu.org> <70f5d04e-48d5-bf0d-fff7-8e7107878d9a@gmail.com> <83shffci4e.fsf@gnu.org> <985db77a-8f22-34c8-a60c-45fe2c2999ea@gmail.com> <83h8vtc3jf.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1506156622 18933 195.159.176.226 (23 Sep 2017 08:50:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 23 Sep 2017 08:50:22 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 To: 28533@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 23 10:50:14 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1dvg8a-0004TB-Sf for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Sep 2017 10:50:13 +0200 Original-Received: from localhost ([::1]:34158 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dvg8i-00067f-BP for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Sep 2017 04:50:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35461) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dvg8U-00063c-9G for bug-gnu-emacs@gnu.org; Sat, 23 Sep 2017 04:50:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dvg8R-0006xl-5F for bug-gnu-emacs@gnu.org; Sat, 23 Sep 2017 04:50:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44809) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dvg8R-0006wY-21 for bug-gnu-emacs@gnu.org; Sat, 23 Sep 2017 04:50:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dvg8Q-0008OK-IN for bug-gnu-emacs@gnu.org; Sat, 23 Sep 2017 04:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Romanos Skiadas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Sep 2017 08:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28533 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28533-submit@debbugs.gnu.org id=B28533.150615655332197 (code B ref 28533); Sat, 23 Sep 2017 08:50:02 +0000 Original-Received: (at 28533) by debbugs.gnu.org; 23 Sep 2017 08:49:13 +0000 Original-Received: from localhost ([127.0.0.1]:53490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dvg7d-0008NE-EI for submit@debbugs.gnu.org; Sat, 23 Sep 2017 04:49:13 -0400 Original-Received: from mail-wm0-f46.google.com ([74.125.82.46]:48028) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dvg7b-0008N0-Nj for 28533@debbugs.gnu.org; Sat, 23 Sep 2017 04:49:12 -0400 Original-Received: by mail-wm0-f46.google.com with SMTP id r136so8805779wmf.2 for <28533@debbugs.gnu.org>; Sat, 23 Sep 2017 01:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=TkngqqjowhRXJGzjm5RK9WfxXt9IThv6xcTlil+kE8o=; b=KhwUuJqIQUSMrw/uRANw3xjJMVx+IB3XvhSMl+WTqwq/xI/r3hDfoGP4YCMhzyq6OB 70hmT9Be9oBJ4bYAyca2Jp1beyLMdxx+ZEaGqRXeRejDRYQZ7EkX4xr3glbuGCeLpVuY TQXyeHnj87izn+MWKRz/kI+UZFNORL4C5NSlgOMXAldT5P0nHIpC1KNHe7BJivwf557s l/hp29gf0V0Y1/PzSs4XRgccAkdUPa9bNGG7Hu0GsC5Nrs5t6QszSsrq8RN5qCOEB7u6 6LvcCeS4WnhiQ7NVk2GU2bQQHD3ZWWQY6BMCplbI0YBo7rUBgjBqNSsJGK/26cZ0WDrk 0yIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=TkngqqjowhRXJGzjm5RK9WfxXt9IThv6xcTlil+kE8o=; b=PqmLJMWNGN4ulYHwazKPeKE/qpgpAyfx19zOIHQSxxhhMX2Pthqzlefu9P7+6wE167 fXuPSHnLSDoHoHnBi7huFsFTce4K0uvSYz6i4C5Ao9MzIPdNbSOgB8YS7zakRkpuzfj9 gErb+NePiupxmtzOUHENvtf3+LBpR4vJhNCaSmLSPVntxPkVa6ocBPcqOSyOzgj6z4Q6 kvOx2Z2KQRSTotOA9C6rTMgg7MotCBhkEdz7zNIt8ANcaaRIL/uJfUR9Cyd2kPBv3WXh JgfvVxqEiDUAZNU/2rHI2HPY9BEw9P+vAnLNEraFYjhP8HBwdcCHgfBx0vRxBLJiwyc/ QD9Q== X-Gm-Message-State: AHPjjUjTSXIJj3bg2ZUId/30BFD7l6lHyKgrJzGMQjfbI1saDFxfJ8uK U8KJC5BIF/dwLX6xtrqAjr9Isrup X-Google-Smtp-Source: AOwi7QCUVo6F396uqDO2dwEw+AFRhGzCJL48B7EOGzQYIfPGPMXGC52cuhT7LLX+4/BIlUTPRxxRcw== X-Received: by 10.80.141.133 with SMTP id r5mr7359784edh.107.1506156545662; Sat, 23 Sep 2017 01:49:05 -0700 (PDT) Original-Received: from [192.168.43.184] ([83.136.43.213]) by smtp.gmail.com with ESMTPSA id j18sm933602edh.93.2017.09.23.01.49.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Sep 2017 01:49:05 -0700 (PDT) In-Reply-To: <83h8vtc3jf.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:137265 Archived-At: > But why in private email? Because I keep accidentally pressing C-r on thunderbird instead of C-R. This is the third time this week I've done this that I know of, sorry. Thanks for taking the time to explain all these things to me. Feel free to close the bug now if you haven't already. >>>> If you think it is a WONTFIX kind of deal, I'm ok with closing it. As >>>> far as I can tell the customizations you suggested are not somewhere in >>>> the docs. Should they added in NEWS and in any other relevant documentation? >>> Not sure what you mean: the variables I mentioned are AFAIK documented >>> in the Emacs manual. >> They are documented, but using them in a way to circumvent this problem >> is not. I might be wrong, so if that is the case let me know. A mention >> in the display-numbers-mode docstring along the lines of "if you fold >> lines in the buffer set such and such variable to X value" would be useful. > I added that now to the Emacs manual. Thanks, I saw that. > >>> Org mode has special needs when non-relative line numbers are >>> displayed, and the solution should IMO be in Org, not in Emacs core, >> There are other ways to hide line numbers, such as >> set-selective-display, which can be used in any mode. There other are >> minor modes that do that too like evil & origami. > they should all adapt, if their users use line-number display a lot. > >>> because solving that in core would mean significant run-time penalties >> How significant? > Very significant: they would require doing each redisplay cycle twice. > > You must understand the problem to see the difficulty: the display > engine calculates the space needed for line-number display just once, > at the beginning, when it is about to display the first line, and then > reuses the result of that calculation for all the subsequent lines. > It estimates the maximum number of lines that can be visible in the > window to do that, but it cannot know in advance how many lines will > be hidden from display without displaying them first. So it would > need to display twice. This is what linum-mode did, and that's the > reason why it was so slow. I don't think it's right to bring that > slowdown back, when reasonable solutions exist on the Lisp level. I see. Thanks for explaining. > , that is good. > >> on the other hand, solving it in core means that every >> mode that folds buffers won't have to solve it themselves or ask their >> users to solve it. > Yes, and why is that a problem? Many modes already have > accommodations for popular minor modes, including linum-mode. Why > cannot they accommodate this new feature as well? > > Solving everything in the core has a price, and good engineering > doesn't punish everyone on behalf of the needs of a few. Let those > few pay the price in adapting. Fair point. > >> Also, on the point of what Emacs calculates as the minimum width, I >> checked with other editors (gedit, the one that starts with V and ends >> with IM) and they calculate the size of the width to be the one of the >> last line in their buffers. > That's what display-line-numbers-width-start does in Emacs. But it > does that once, when the buffer is first created. Counting all the > lines in the buffer upon each redisplay cycle would be prohibitively > slow in large buffers, so Emacs doesn't do that. However, if you > customize display-line-numbers-grow-only as well, you will have the > best of all worlds. > >> So if the last line is 1234 the width is 4 regardless of where you >> are in the buffer. The problem wouldn't show up if Emacs calculated >> the width this way, would it? This way of calculating things has the >> added benefit that if you scroll up the buffer when line ~100 is at >> the bottom the text doesn't suddenly shift right by one, which I >> find really annoying. > If this annoys you, you should set display-line-numbers-grow-only > non-nil. Ah, thanks.