From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#71323: 28.2; global-display-line-numbers-mode in org file do strange identation when headers are folded Date: Sun, 02 Jun 2024 15:20:41 +0300 Message-ID: <86le3nmt7q.fsf@gnu.org> References: <994aaad088f1e26429986a95996a02e7b9d4a1a3.camel@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4446"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71323@debbugs.gnu.org To: Mikhail Efremov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jun 02 14:22:16 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sDkE2-0000y5-Ra for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 02 Jun 2024 14:22:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sDkDk-0008IW-4u; Sun, 02 Jun 2024 08:21:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sDkDi-0008IA-FF for bug-gnu-emacs@gnu.org; Sun, 02 Jun 2024 08:21:54 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sDkDd-0000bS-LR for bug-gnu-emacs@gnu.org; Sun, 02 Jun 2024 08:21:54 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sDkDp-0007tx-MQ for bug-gnu-emacs@gnu.org; Sun, 02 Jun 2024 08:22:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 02 Jun 2024 12:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71323 X-GNU-PR-Package: emacs Original-Received: via spool by 71323-submit@debbugs.gnu.org id=B71323.171733087230298 (code B ref 71323); Sun, 02 Jun 2024 12:22:01 +0000 Original-Received: (at 71323) by debbugs.gnu.org; 2 Jun 2024 12:21:12 +0000 Original-Received: from localhost ([127.0.0.1]:58011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sDkCu-0007sT-Fr for submit@debbugs.gnu.org; Sun, 02 Jun 2024 08:21:12 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:57050) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sDkCr-0007ro-GV; Sun, 02 Jun 2024 08:21:03 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sDkCZ-0000Uu-Pw; Sun, 02 Jun 2024 08:20:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=8yJzVXIcysI+7r3Qfq2eMAaQS2fhSYsixRZSd1r/Fo0=; b=CZfkPFjGxNUrV4R8qBUz oBDMB+NrZ8aelx9qvWeFatU3DeCnLOrKUqjVCL4qMZjytV1U0DOWQwsMml6iHQvBouWvvjgLM0qPh cvxWSnWVWUo0qDCXJ6UMkshhsb2ic09GoKs723LEMRlpfTRZjtKctqYqM/IDqtXcJGn00fZanqawc iJe0r8G5w7+bv1ez+8M2qlODPWpW1p763vwNQAjLZyCJ8jgqoRRhewUSv+evtVyE1gvakeBkVDYBq uhYq93SoeNPXwhTUSUE8Pp93dpytC/NFNk3DrKGdrf5yz1pEVFlTc6xwPSP0mjgtNpe4lebpfEfqm cr/GyNePQx/JZg==; In-Reply-To: <994aaad088f1e26429986a95996a02e7b9d4a1a3.camel@gmail.com> (message from Mikhail Efremov on Sun, 02 Jun 2024 15:10:46 +0600) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:286387 Archived-At: tags 71323 notabug thanks > From: Mikhail Efremov > Date: Sun, 02 Jun 2024 15:10:46 +0600 > > * Description > > There is an issue with not so large org files with > global-display-line-numbers-mode is toggled on. You may reproduce it: > > 1. ~emacs -Q~ > 2. open an org file with 1000+ lines of different headers' layers > unfolded. > 3. ~M-x global-display-line-numbers-mode~ > 4. Check that unfolded headers on lines 999-1000 are indented fine: >   - numbers are right-aligned; >   - same-level headers are indented equally with the same indent width >   relative to line numbers. > 5. Fold all headers with the property: on the screen of the buffer > there > are single-, two- and three-digits lines' numbers are presented. > > Then, you should see the picture like this: > >   1 * header1 >  24 * header2 > 132 * header3 > 1019 * header4 > > The same behavior is on ~emacs -nw -Q~. > > The issue is valid also on built from sources emacs: GNU Emacs 29.3 > (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version > 1.16.0) of 2024-04-08 > > * Motivation > > This behavior on the one hand constantly shifts > left-to-right-and-vice-versa the buffer's text and also confuses with > headers' identation level. > > * Definition of Done > > After the steps of reproducing the desired view is: >    1 * header1 >   24 * header2 >  132 * header3 > 1019 * header4 You should be able to have this if you customize display-line-numbers-width-start to a non-nil value. Consider also customizing display-line-numbers-grow-only to a non-nil value. > * Details of implementation > > I guess there is a problem with line's mode algorithm, from my side > it looks like it taking into account only 1 digit difference for an > identation, then if there is 2 or more digits differnece, then all > after the first-digit diff identations are broken. No, that's not what happens. The problem is that the required width of the line-number display needs to be calculated when the window is about to be shown on display or redisplayed due to scrolling etc. At that time, the display-engine code which does this calculation cannot know up front how many lines are hidden by 'invisible' text properties and overlays, something that Org uses a lot, and therefore cannot correctly estimate the largest line number to be shown. So its estimation of the maximum number of the line in the window are incorrect in those cases. Customizing display-line-numbers-width-start fixes that problem, for a price of a slightly slower initial display of the window. It could still fail if you add a lot of lines to the buffer, in which case toggling display-line-numbers-mode off and on again should fix it. > The posible solution is to count total lines number and reserving > line's numbers side width from total lines count number's width. That's exactly what the above user option does, when non-nil. There's no bug here.