From unknown Sun Jun 22 11:48:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#31717: 26.1; display-line-numbers-mode enlarges indicator without need Resent-From: Carlos Pita Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Jun 2018 02:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 31717 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 31717@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.152816612713971 (code B ref -1); Tue, 05 Jun 2018 02:36:01 +0000 Received: (at submit) by debbugs.gnu.org; 5 Jun 2018 02:35:27 +0000 Received: from localhost ([127.0.0.1]:33809 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQ1ok-0003dH-J5 for submit@debbugs.gnu.org; Mon, 04 Jun 2018 22:35:26 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42144) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQ1oi-0003d4-V6 for submit@debbugs.gnu.org; Mon, 04 Jun 2018 22:35:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fQ1ob-0003av-GL for submit@debbugs.gnu.org; Mon, 04 Jun 2018 22:35:19 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:35129) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fQ1ob-0003ar-Ci for submit@debbugs.gnu.org; Mon, 04 Jun 2018 22:35:17 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fQ1oX-0001ne-W2 for bug-gnu-emacs@gnu.org; Mon, 04 Jun 2018 22:35:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fQ1oQ-0003Wf-Ti for bug-gnu-emacs@gnu.org; Mon, 04 Jun 2018 22:35:12 -0400 Received: from mail-qt0-x231.google.com ([2607:f8b0:400d:c0d::231]:37196) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fQ1oQ-0003WV-Nv for bug-gnu-emacs@gnu.org; Mon, 04 Jun 2018 22:35:06 -0400 Received: by mail-qt0-x231.google.com with SMTP id q13-v6so893371qtp.4 for ; Mon, 04 Jun 2018 19:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=ZuZjTcSFP33yyUBZ1bwun90t7YRc1+no4WQmkmYRWTo=; b=FDquo5NJ8MuLmnDz+LnFoS0P/6QoxpRcDQRk8QVWbzt00XYYjbx98uDfC92IfPWnF9 4vzHxOQUcZpheQqSX3Ma3VA7VspgFZaLrF0dWJJdGjiEILWdCK4AzSqITa3SNZKbXe33 p2+monwjqN19GioU4Ek+lietA/9/c0KAnTk6OpV5CXpSKx71dQU0kJ37OBnTCN5dsoD1 qHzXtiUTuDTft/q4tGqBKlrz4F2YB1DS8nQjEWv7HkWUOtOhkF7pqNkDMxGEYOYMYEQv fRAr6HmmxzHTpMWBQ68lOiVGfju32Oh7Zj2w2fRsB76ZdomLtf4+DlvyOtjds57s3cC7 bl6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=ZuZjTcSFP33yyUBZ1bwun90t7YRc1+no4WQmkmYRWTo=; b=g0384+BvRaJV4oyy4r05hzLkYBRZRbr3rh2GCkTPIgNbEezYnFRAb5fte7W4VlbItP 4uJn613Dm9SLfzYWdp1FXZm0XdnJqZX/Rp1qPoe8PGdCxW/plx3I+0cb59izZN2Za9BT M0pZoVstkDTaHvVtEVxVentnjI7NHGS+lNWL2V9zgEZ8sF/qpMMsRCXjC5Ox6Q0QIYDG af4eGYs/L84UcA50fzNV5R8RcKHhLEZdFNhtmjsNCRnZz9vYhsUk9xFwddL2LikP2xWd qPKYM0ZJVP/6ckMlRj1h7ZK8jD4bvPofSR/z0fcqotrFrpJdmkFLWRV0jfyG9mIA8dIe 8zSA== X-Gm-Message-State: APt69E1m7MeBwU76gyCXpk3InTAqGL7l1z08QsJB0TthQhMwQTQfuxZx pMUUUWqJjIqQEp4f+ApHnlkXAQ== X-Google-Smtp-Source: ADUXVKKE7FUDXr6UQ1lI7NcASv8cCoOF1LcRw8RyeUzpb7l8B5fDs0VLBLARC99hWS4KUwUOEc0OvA== X-Received: by 2002:ac8:3338:: with SMTP id t53-v6mr22069928qta.312.1528166105791; Mon, 04 Jun 2018 19:35:05 -0700 (PDT) Received: from carlos ([190.2.33.33]) by smtp.gmail.com with ESMTPSA id t6-v6sm14839107qtn.86.2018.06.04.19.35.04 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 04 Jun 2018 19:35:05 -0700 (PDT) From: Carlos Pita Date: Mon, 04 Jun 2018 23:34:52 -0300 Message-ID: <87vaaym04z.fsf@carlos.i-did-not-set--mail-host-address--so-tickle-me> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) When transitioning from line 69 to line 70 a new column is added to the left of the indicator as if there was a need to fit three digits despite that the file has less than 100 lines and despite that if it were larger line 100 would fall out of the window. I have tested the transition from 969 to 970 and it shows the same effect. It's as if the mode is anticipating an extra digit soon and playing conservative. I understand that there could be performance reasons for doing this (thus avoiding the need to compute the remaining lines in a window or file) but: 1. The mode is already adding two whitespaces around the line number indicator. Wasting one more char is on the verge of infuriating ;) 2. AFAICS computing the file size doesn't seem too demanding a task, neither the remaining lines in a window (although the window could be resized). --- In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2018-05-29 built on juergen Windowing system distributor 'The X.Org Foundation', version 11.0.11906000 System Description: Manjaro Linux Recent messages: Quit [2 times] C-h C-g is undefined nil Quit Display-Line-Numbers mode disabled in current buffer x is undefined Display-Line-Numbers mode enabled in current buffer 0 (#o0, #x0, ?\C-@) scroll-down-command: Beginning of buffer [3 times] Making completion list... Configured using: 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-modules 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt' CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 MODULES THREADS LIBSYSTEMD LCMS2 Important settings: value of $LC_MONETARY: en_US.UTF-8 value of $LC_NUMERIC: en_US.UTF-8 value of $LC_TIME: en_US.UTF-8 value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Info Minor modes in effect: display-line-numbers-mode: t diff-auto-refine-mode: t pyvenv-mode: t shell-dirtrack-mode: t ido-everywhere: t winner-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t column-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils pp cl-print jka-compr vc-git display-line-numbers doom-tomorrow-night-theme doom-themes doom-themes-common cl-extra yasnippet elec-pair highlight-indentation flymake-proc flymake warnings company edmacro kmacro pcase help-fns radix-tree help-mode elpy find-file-in-project ivy delsel ivy-overlay ffap thingatpt diff-mode easy-mmode elpy-shell pyvenv esh-var esh-io esh-cmd esh-opt esh-ext esh-proc esh-arg esh-groups eshell esh-module esh-mode esh-util elpy-profile elpy-django s elpy-refactor subr-x python tramp-sh tramp tramp-compat tramp-loaddefs trampver ucs-normalize shell pcomplete parse-time format-spec advice json map ido grep compile comint ansi-color files-x etags xref project cus-edit cus-start cus-load wid-edit winner ring windmove finder-inf info package easymenu epg-config url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 395972 45995) (symbols 48 33197 1) (miscs 40 181 236) (strings 32 77765 6307) (string-bytes 1 2252569) (vectors 16 53016) (vector-slots 8 923948 18050) (floats 8 186 268) (intervals 56 4758 0) (buffers 992 16)) From unknown Sun Jun 22 11:48:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#31717: References: <87vaaym04z.fsf@carlos.i-did-not-set--mail-host-address--so-tickle-me> In-Reply-To: <87vaaym04z.fsf@carlos.i-did-not-set--mail-host-address--so-tickle-me> Resent-From: Carlos Pita Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Jun 2018 02:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31717 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 31717@debbugs.gnu.org Received: via spool by 31717-submit@debbugs.gnu.org id=B31717.152816731215713 (code B ref 31717); Tue, 05 Jun 2018 02:56:01 +0000 Received: (at 31717) by debbugs.gnu.org; 5 Jun 2018 02:55:12 +0000 Received: from localhost ([127.0.0.1]:33827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQ27s-00045N-4j for submit@debbugs.gnu.org; Mon, 04 Jun 2018 22:55:12 -0400 Received: from mail-io0-f170.google.com ([209.85.223.170]:42777) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQ27q-00045A-Gd for 31717@debbugs.gnu.org; Mon, 04 Jun 2018 22:55:10 -0400 Received: by mail-io0-f170.google.com with SMTP id r24-v6so1474443ioh.9 for <31717@debbugs.gnu.org>; Mon, 04 Jun 2018 19:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=RsAZdqeIb44JAAtxNvH/L3rvCAa35Lm+6GjhrQZ6Huk=; b=Xp8SdIoEb1LLn1oNZ1iyG1LDho3lM64gZjaKwRvPXXJz4OLmCb34Z1X6DfZLDOPgDV F6BOT+pWdsqgREYJnNHFkTNi6EWFUECpRymDJM2WDB6YJpWgIV83rDbY7YMoK3L4Jw1Y JBJtzULeL63xaHMxE4ETpyztzK54Up4cq5Vytf/gDuiNwqVZf9XAcWRkEndOXLJoOT0m 1B5se9oC55r2/42XRMcwn3nO9R35S8jjZWlflh/2FXwnYZ20RmF2g+zC9H//RHYn5ZGV qpC9iX9vfl13fRTxVyv9Qb2q7NY599YWJZO3G87e0ptBlobZla+yIYOIyFHHQwcUW3tt vc1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RsAZdqeIb44JAAtxNvH/L3rvCAa35Lm+6GjhrQZ6Huk=; b=ELwVk3hCiqjc8U9FaWWOoMuQzuJ+oTpfDOw9NAYsHoKWWs0ey3LWzBhsaRWEYg9GNG uDG4x0t9QpnXVqkE4FJlCvYbWiwmOdAPoYQB6a7V3HSO+1Y1EH8qvvLMR4f+i5IFj/dc El7Q1iMNseOs2y2C4mr6aB8a30+CxvFhKfbCI++g5QcfH/17fnlk9m5v62FOmPdVNC3A 9vFsUJOgsRQMlSDKQ4+t4NfVBrvlhYnTvDMzT9jteQVzBcM2oDYDsD/TpDltH/UsiQ0Q TXRSnQ4ye6E8RW/FfJK52QxVpU16uFrYBE9yPoHgdyM1kBE8y+s2e+AsiHD0jcfkyVBQ eVGg== X-Gm-Message-State: APt69E1je/7yj/hRXL72hPoQ2lV9pQLy37IDQrg9bEnQY/BHq63Ykfgj OIkOeB0LgQ9p7Esr+D98dk5Lo3GLaEmpiYGEwt8= X-Google-Smtp-Source: ADUXVKKbjF7BlsNBoxo9rv651S5h83Qt4T45tq5jUU4fHNc187jgy1J/h+J4hfp0HtN04O3Yx2u7ur33KRY3Ob26Gv8= X-Received: by 2002:a6b:bfc1:: with SMTP id p184-v6mr24421009iof.80.1528167304514; Mon, 04 Jun 2018 19:55:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:a98e:0:0:0:0:0 with HTTP; Mon, 4 Jun 2018 19:54:44 -0700 (PDT) From: Carlos Pita Date: Mon, 4 Jun 2018 23:54:44 -0300 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Also, when the mode is visual or relative this is happening too. In these cases, given that I assume you are assuming <= 69 is a safe guess, it will be *always* safe to limit the indicator width to that required by the current line. [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.223.170 listed in list.dnswl.org] -0.8 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.223.170 listed in wl.mailspike.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (carlosjosepita[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 2.0 BLANK_SUBJECT Subject is present but empty X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) Also, when the mode is visual or relative this is happening too. In these cases, given that I assume you are assuming <= 69 is a safe guess, it will be *always* safe to limit the indicator width to that required by the current line. So this would be an easy optimization: in visual and relative modes never anticipate an additional digit. From unknown Sun Jun 22 11:48:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#31717: References: <87vaaym04z.fsf@carlos.i-did-not-set--mail-host-address--so-tickle-me> In-Reply-To: <87vaaym04z.fsf@carlos.i-did-not-set--mail-host-address--so-tickle-me> Resent-From: Carlos Pita Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Jun 2018 03:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31717 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 31717@debbugs.gnu.org Received: via spool by 31717-submit@debbugs.gnu.org id=B31717.152816943918822 (code B ref 31717); Tue, 05 Jun 2018 03:31:02 +0000 Received: (at 31717) by debbugs.gnu.org; 5 Jun 2018 03:30:39 +0000 Received: from localhost ([127.0.0.1]:33835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQ2gA-0004tV-VB for submit@debbugs.gnu.org; Mon, 04 Jun 2018 23:30:39 -0400 Received: from mail-io0-f176.google.com ([209.85.223.176]:36966) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQ2g9-0004tC-7O for 31717@debbugs.gnu.org; Mon, 04 Jun 2018 23:30:37 -0400 Received: by mail-io0-f176.google.com with SMTP id s26-v6so1563611ioj.4 for <31717@debbugs.gnu.org>; Mon, 04 Jun 2018 20:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2fE/jNNfkDiTJK4c0/NLg8sJk6VmNCZQCBLUTnukv68=; b=uSPjpcQjG0xkJqesvFb1hhKERIl+L79NnTIN+hOe7huxRUOWOBl6dbMJATjGaQmsHE JfPwR1vrFYkMDGEfyxqfmaz+EV/W2O6MMVuJIdivfLRrN9FkHAFx4ngBcMDZgxLlfAMm 80Yk9yVDp8pjiPzIX5zun8fpHkfOECZVLE4BLGpRFxfVWoPe1yCKrCTL8o+InZ7UFhx0 0WT7Fkr4FPvwUCCLWAKmsmvDVqprl5DXlwgen7GjQhM/joLSddMYT+NDg0rPa1+QiH4M fmqewX9LlPfwQpkxCnygkj0tamayHvQpjEOELCi3QeA5GNtoHrtK1iav1xvjRFvpUIfm JXFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2fE/jNNfkDiTJK4c0/NLg8sJk6VmNCZQCBLUTnukv68=; b=dCkeVCUne/Dbp5jroydvq3Y7WJsSzAxbvjXJXju0iQ7QLINCQnfFzNDPMcSUC65Vn6 vjHTolLW9ptclIm1dqqzVlfIFnqoiJB8i8hwekkFnKjkNQm9eWV//Waba/cGr7ZGj7bd U8CiZTxRcgrMPNAIlnlbp0pnLHN0FhHLU7zA8T8fYlwZMCHJDbqV73tFg+TSrI5IeI+J 7kNz3FqRBK3e/g0MeQ6vRZ5AJ3okgh/IbiZh+u3+ZlHIVYVnpo8VG56p4gNHDnr42zZQ Ztrcl76K1N5sEGu7/q6GqNTrYljifakD7c/bx5qWMJ/+xi1+3pSyLmFUGJK0xsZfdAyq Rquw== X-Gm-Message-State: ALKqPwcGQO2ca6YnFbaC9B0qAWJHqJqkezR4nsMsQhM4NXO7afzF8eEq oJubWUI3M+e/vaA9qRkvwWTuyz4NtOkRQz6nIxg= X-Google-Smtp-Source: ADUXVKJD9VxPdfN/6DyppPlUYdWWLtvGJSDcYv7AMI72stg8q+4hLeKY1HMBptlf4pQJj0C1n2vKFhU04Sk0xPXNfaE= X-Received: by 2002:a6b:2b10:: with SMTP id r16-v6mr23261077ior.204.1528169431457; Mon, 04 Jun 2018 20:30:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:a98e:0:0:0:0:0 with HTTP; Mon, 4 Jun 2018 20:30:10 -0700 (PDT) From: Carlos Pita Date: Tue, 5 Jun 2018 00:30:10 -0300 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: A little more experimentation with different windows sizes made me realize that the <70 hard and fast rule doesn't exist. Now I see the threshold indeed depends on the window size. But it is still too conservative, leading to premature enlargement of the line number space. [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.223.176 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (carlosjosepita[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 2.0 BLANK_SUBJECT Subject is present but empty X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) A little more experimentation with different windows sizes made me realize that the <70 hard and fast rule doesn't exist. Now I see the threshold indeed depends on the window size. But it is still too conservative, leading to premature enlargement of the line number space. I suggest three optimizations in order of assumed (wild guessed) ascending difficulty: 1. For relative/visual modes never reserve extra space. 2. If the lines in the file are < N never reserve extra space for >= N. 3. Take also into account the remaining window lines (I assume this is not as easy as it sounds). From unknown Sun Jun 22 11:48:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#31717: 26.1; display-line-numbers-mode enlarges indicator without need Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Jun 2018 14:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31717 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Carlos Pita Cc: 31717@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 31717-submit@debbugs.gnu.org id=B31717.152820858021257 (code B ref 31717); Tue, 05 Jun 2018 14:23:01 +0000 Received: (at 31717) by debbugs.gnu.org; 5 Jun 2018 14:23:00 +0000 Received: from localhost ([127.0.0.1]:35232 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQCrU-0005Wm-1k for submit@debbugs.gnu.org; Tue, 05 Jun 2018 10:23:00 -0400 Received: from eggs.gnu.org ([208.118.235.92]:50450) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQCrR-0005WZ-Rd for 31717@debbugs.gnu.org; Tue, 05 Jun 2018 10:22:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fQCrK-00054z-Lr for 31717@debbugs.gnu.org; Tue, 05 Jun 2018 10:22:52 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44612) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fQCrA-00050P-OZ; Tue, 05 Jun 2018 10:22:40 -0400 Received: from [176.228.60.248] (port=3814 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fQCrA-0003QM-7B; Tue, 05 Jun 2018 10:22:40 -0400 Date: Tue, 05 Jun 2018 17:22:50 +0300 Message-Id: <83fu21b9dx.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Carlos Pita on Tue, 5 Jun 2018 00:30:10 -0300) References: <87vaaym04z.fsf@carlos.i-did-not-set--mail-host-address--so-tickle-me> 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-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) tags 31717 notabug thanks > From: Carlos Pita > Date: Tue, 5 Jun 2018 00:30:10 -0300 (Sorry for a longish response, but you raise design and implementation issues which cannot be explained without some non-trivial background.) > When transitioning from line 69 to line 70 a new column is added to the > left of the indicator as if there was a need to fit three digits despite > that the file has less than 100 lines and despite that if it were larger > line 100 would fall out of the window. Right, this is the intended behavior, and there are good reasons for it. See below. > It's as if the mode is anticipating an extra digit soon and playing > conservative. I understand that there could be performance reasons for > doing this (thus avoiding the need to compute the remaining lines in a > window or file) The main reason is performance, but it's not the only one. You must keep in mind that the code which produces line numbers is part of the display engine -- it produces the line number as part of that line's layout -- and that imposes very specific restrictions and conditions on what we can do, how, and when. I try to explain the issues below in more detail, but the main point is that you simply _cannot_ think about stuff done in redisplay as if it were some Lisp program running off post-command-hook or somesuch, it's a very different runtime environment with peculiar requirements. > but: > > 1. The mode is already adding two whitespaces around the line number > indicator. Wasting one more char is on the verge of infuriating ;) If you don't want to "waste" one more column, you can use one of the optional features, e.g., set display-line-numbers-width-start non-nil, with or without display-line-numbers-grow-only non-nil. > 2. AFAICS computing the file size doesn't seem too demanding a task, > neither the remaining lines in a window (although the window could be > resized). Doing this as part of a redisplay cycle is precisely what made linum mode so slow. In a nutshell, it would require displaying each window twice, because the exact number of lines in a window is known only after it was completely redrawn (remember that Emacs supports variable-size fonts and non-character display elements such as images, which all affect the number of lines in a window). As for computing the number of lines in a buffer, I guess you never have to deal with very large buffers, if you think it's scalable. With today's 64-bit architecture, the maximum buffer size supported by Emacs is too huge to allow us to count lines all the time; plus, as I explain below, the display code which produces line numbers is called much more than you evidently assume. > Also, when the mode is visual or relative this is happening too. By default, visual and relative line numbers still display the absolute line number for the current line, so we still need enough space for that. And the current line could be the last line of the window. (And if you think the fact that only the current line needs this makes the life of the implementation easier, read on, and you will understand why not.) > In these cases, given that I assume you are assuming <= 69 is a safe > guess, it will be *always* safe to limit the indicator width to that > required by the current line. As you later discovered, there's no 69 value anywhere in the code, the space needed for the line-number display is estimated dynamically and depends on the window size and the font size used by the window's frame. For a very large window, the switch could be much sooner than line 69; for a very small window, it could be very close to 100. > A little more experimentation with different windows sizes made me > realize that the <70 hard and fast rule doesn't exist. Now I see the > threshold indeed depends on the window size. But it is still too > conservative, leading to premature enlargement of the line number > space. It _must_ be conservative, because it needs to decide on the space for the line numbers _before_ it displays the first line of the window. Here's some background information regarding the requirements imposed by the display engine on the line-number implementation: The Emacs display engine works by "screen lines". (A screen line is a single horizontal line of the display "canvas"; continuation lines count as additional screen lines.) The workhorse of the display engine is a function that lays out a single screen line. In some cases Emacs invokes that function to redraw all the lines of a window, one by one; in other cases, the function is invoked to produce only a few screen lines, or even just one, when Emacs is able to decide up front that none of the other screen lines need to change on display -- being able to do this is an important part of Emacs redisplay optimizations. In addition, Emacs needs to take text layout on display into consideration in many situations that have little to do with actual redisplay. For example, vertical-motion (which is the basis of any vertical cursor movement and scrolling commands) needs to determine the character directly below or above the character at point, something that obviously depends on the stuff displayed between point and that other place, the faces involved, etc. As another example, consider a mouse click inside the window, where Emacs needs to know the buffer position at the click coordinates. For these reasons, the display routines that perform layout calculations are used _a_lot_ in Emacs, and must (a) be very efficient, and (b) produce consistent results no matter whether they are called to redraw the entire window or just a small part thereof. In particular, the functions that lay out a single screen line have no idea about the context in which they were called -- they don't know whether they are called as part of a complete window redisplay, or just to draw a single screen line. They must produce exactly the same results regardless, and without depending on any such context. I hope you are now beginning to understand why the feature works as it does. The code must calculate the space required for line-number display before it displays the first line of a window, and the result must be guaranteed to fit for all the lines in that window, because otherwise some window line near the end might need more space, and you will either have an ugly "jagged" display, or will need to abandon the redisplay cycle and trigger another cycle -- which will be slow (that's basically what linum.el does, and we already know it's slow). How do we estimate the largest line number to be displayed in the window in a way that is never too small? Well, the display engine keeps an estimation of the maximum number of screen lines in the window, based on the fonts defined by the frame -- it needs to know that because that defines the dimensions of the canvas used for displaying the window. So we simply reuse that estimation for this purpose. That estimation is always a conservative one, and it cannot be any other way. (Btw, it is much less conservative on TTY frames, for obvious reasons, so there you will see much less "waste".) > I suggest three optimizations in order of assumed (wild guessed) > ascending difficulty: > > 1. For relative/visual modes never reserve extra space. Cannot be done, because when the space for line numbers is computed, Emacs doesn't yet know what will be the current line, nor where in the window it will be. The current line, which is the line that displays the cursor, is computed only near the end of the redisplay cycle of a window. And the code must use the same conservative estimate to be able to display the largest line number possible. If you don't need to see the absolute line number in relative mode, customize display-line-numbers-current-absolute to nil, and the "waste" will indeed be no more. > 2. If the lines in the file are < N never reserve extra space for >= N. Can't be done by default, because counting lines in a very large buffer will slow down redisplay and any command that uses display code (see above). It would also cause unpleasant redrawing and horizontal movement of text when you add lines at the end of the buffer. However, you can have this as an optional feature, if you customize display-line-numbers-width-start to a non-nil value. > 3. Take also into account the remaining window lines (I assume this is > not as easy as it sounds). Can't be done, because it would require a second redisplay cycle, which will get us back to the same performance problem as we have in linum.el. I didn't write this feature just to have it work as slow as linum.el, only in C ;-) (Of course, if someone has clever ideas how to improve line-number display, please speak up, but you should make yourself familiar with the related code in the display engine first.) I hope the above explains why we have the implementation we have. All in all, I find the price entirely reasonable, given the performance gains (the default configuration works with line numbers almost as fast as without them). And we have a few customizable options to optionally enable features which alleviate some of these issues, for those who are willing to pay the price. P.S. Please make a point of keeping the full title of the bug in your responses and followups, because removing the title and leaving just the bug number makes it much harder to find all the messages that pertain to the same bug, at least with Rmail. Thanks. From unknown Sun Jun 22 11:48:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#31717: 26.1; display-line-numbers-mode enlarges indicator without need Resent-From: Carlos Pita Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Jun 2018 15:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31717 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Eli Zaretskii Cc: 31717@debbugs.gnu.org Received: via spool by 31717-submit@debbugs.gnu.org id=B31717.152821202417506 (code B ref 31717); Tue, 05 Jun 2018 15:21:01 +0000 Received: (at 31717) by debbugs.gnu.org; 5 Jun 2018 15:20:24 +0000 Received: from localhost ([127.0.0.1]:35344 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQDl1-0004YH-PB for submit@debbugs.gnu.org; Tue, 05 Jun 2018 11:20:23 -0400 Received: from mail-io0-f180.google.com ([209.85.223.180]:42579) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQDkz-0004Y4-Uw for 31717@debbugs.gnu.org; Tue, 05 Jun 2018 11:20:22 -0400 Received: by mail-io0-f180.google.com with SMTP id r24-v6so3791975ioh.9 for <31717@debbugs.gnu.org>; Tue, 05 Jun 2018 08:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ha1p/nTuWmOGkGHL+6RiYDPSAiDY4ClZE6Y1iC5mZNE=; b=KNE9xsv4Wv8kRTeg9Fnh9sbYPXpd/SaYixcOtBnfueJaB/a6qQQ5R6005Is7xVTzJ/ llwZZFuaS2W/D5fFTOZW7J+A6nSYfXNeSk6NZTRXNdkVjJaNa4ApTe6mOIrMxBIc+eGs 2KTYzeilslrEZxqReyrwJrYOhM9d6viiWTXtiNLAgyaKc5DaSkz0vx4d6TpGXhHfPzoG lda0EhSP72WHWGGI10mfAGCDLLhm1H2eiHFQCJ8HF6gpDjEx9Sy7XFMBePrFoOjeczRc 0DnYl5RRCujhiC/ijl/5qB9p8DE2lDesWM4vlvo+QUDa/+gTaAH0r7ey2xmyCwghyEgY 3vPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ha1p/nTuWmOGkGHL+6RiYDPSAiDY4ClZE6Y1iC5mZNE=; b=HS+HjvzIhKgcBe2hNfALdpHwLHvIkEzXE6O8TuTj7MMp0kkyxPFByRZydijcv9aRsF C40slOWUZRJ5WYmIR05raFEjtbWAk28Kgf21K6PLoVBOIQigsj0mjhdVVP3Ce5xoY6aN QvjBfHSZYieHRVg+dlBnwZ4c93T1WOeFcQaJdGpMU9vz6DWjLwtw22i24BN1vO129FQ7 IArCFbOBUGorY0SR3kf5dQU5DPANMwFdSkUFTL93m9ijMqvG9OFiWo176Ky+C8v9vkRj 63+PIBvB3jA5IZ4vmqQd+ZYLxP3SzTWQB/uGB+ONJZuZ/eBIOS54kgh8YK05Jf/Dt8Nl A1QA== X-Gm-Message-State: ALKqPweRKqWQH3DfDM29KBIJqGEfgraYij0KvgWrRJjQlkUR6yMrMzv2 W2DZWoOk9XMdq5WZeqrdLQERhCudbp6ZXqo94Aw= X-Google-Smtp-Source: ADUXVKK0Olp08RY8cX15LEkOBfoKchMYgA79JAmnvCaMeSuVNffUyF9bkHVnKCgoON/dKCOh5xQ1H5uCxAivkL2khaY= X-Received: by 2002:a6b:882a:: with SMTP id k42-v6mr25997402iod.137.1528212016366; Tue, 05 Jun 2018 08:20:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:a98e:0:0:0:0:0 with HTTP; Tue, 5 Jun 2018 08:19:55 -0700 (PDT) In-Reply-To: <83fu21b9dx.fsf@gnu.org> References: <87vaaym04z.fsf@carlos.i-did-not-set--mail-host-address--so-tickle-me> <83fu21b9dx.fsf@gnu.org> From: Carlos Pita Date: Tue, 5 Jun 2018 12:19:55 -0300 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Thanks Eli for such an informative and detailed answer! It's worth posting it somewhere more available, I will do something about that in due time. > If you don't want to "waste" one more column, you can use one of the > optional features, e.g., set display-line-numbers-width-start non-nil, > with or without display-line-numbers-grow-only non-nil. I'm failing to see how this would prevent the "wasteful" behavior. Are you just saying that if I reserve all the space in advance I won't be seeing the widening happening since it have already happened up front? I understand all your points above, so I'm going to ask for a more modest alternative: the ability to suppress the left, right or both whitespaces in the indicator. Do you think this is worth opening a new issue or will it be rejected instantaneously/ignored for ever? Again, thanks for taking the time to explain! From unknown Sun Jun 22 11:48:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#31717: 26.1; display-line-numbers-mode enlarges indicator without need Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Jun 2018 15:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31717 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Carlos Pita Cc: 31717@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 31717-submit@debbugs.gnu.org id=B31717.152821346719752 (code B ref 31717); Tue, 05 Jun 2018 15:45:02 +0000 Received: (at 31717) by debbugs.gnu.org; 5 Jun 2018 15:44:27 +0000 Received: from localhost ([127.0.0.1]:35379 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQE8J-00058W-6P for submit@debbugs.gnu.org; Tue, 05 Jun 2018 11:44:27 -0400 Received: from eggs.gnu.org ([208.118.235.92]:54707) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQE8H-00058H-H2 for 31717@debbugs.gnu.org; Tue, 05 Jun 2018 11:44:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fQE89-0004lc-71 for 31717@debbugs.gnu.org; Tue, 05 Jun 2018 11:44:20 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46062) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fQE89-0004lW-3T; Tue, 05 Jun 2018 11:44:17 -0400 Received: from [176.228.60.248] (port=3946 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fQE87-0001jZ-7f; Tue, 05 Jun 2018 11:44:15 -0400 Date: Tue, 05 Jun 2018 18:44:26 +0300 Message-Id: <83muw99r1h.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Carlos Pita on Tue, 5 Jun 2018 12:19:55 -0300) References: <87vaaym04z.fsf@carlos.i-did-not-set--mail-host-address--so-tickle-me> <83fu21b9dx.fsf@gnu.org> 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-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Carlos Pita > Date: Tue, 5 Jun 2018 12:19:55 -0300 > Cc: 31717@debbugs.gnu.org > > > If you don't want to "waste" one more column, you can use one of the > > optional features, e.g., set display-line-numbers-width-start non-nil, > > with or without display-line-numbers-grow-only non-nil. > > I'm failing to see how this would prevent the "wasteful" behavior. Are > you just saying that if I reserve all the space in advance I won't be > seeing the widening happening since it have already happened up front? AFAIU, it will reserve exactly the space needed by the number of lines in the file. > I understand all your points above, so I'm going to ask for a more > modest alternative: the ability to suppress the left, right or both > whitespaces in the indicator. This produces ugly display, so I don't think it's a good idea. If you want to reserve less space for the line numbers, just customize the line-number face to use a smaller font. From unknown Sun Jun 22 11:48:52 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Carlos Pita Subject: bug#31717: closed (Re: bug#31717: 26.1; display-line-numbers-mode enlarges indicator without need) Message-ID: References: <87vaaym04z.fsf@carlos.i-did-not-set--mail-host-address--so-tickle-me> X-Gnu-PR-Message: they-closed 31717 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: notabug Reply-To: 31717@debbugs.gnu.org Date: Thu, 03 Oct 2019 20:41:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1570135262-25987-1" This is a multi-part message in MIME format... ------------=_1570135262-25987-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #31717: 26.1; display-line-numbers-mode enlarges indicator without need which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 31717@debbugs.gnu.org. --=20 31717: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D31717 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1570135262-25987-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 31717-done) by debbugs.gnu.org; 3 Oct 2019 20:40:07 +0000 Received: from localhost ([127.0.0.1]:41350 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iG7tO-0006jb-RW for submit@debbugs.gnu.org; Thu, 03 Oct 2019 16:40:07 -0400 Received: from mail-pf1-f170.google.com ([209.85.210.170]:44883) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iG7tM-0006iz-N6 for 31717-done@debbugs.gnu.org; Thu, 03 Oct 2019 16:40:05 -0400 Received: by mail-pf1-f170.google.com with SMTP id q21so2453325pfn.11 for <31717-done@debbugs.gnu.org>; Thu, 03 Oct 2019 13:40:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=5WH057635fDxs9IYFpPrESCISPS+bUFXLRub8HP9Gxo=; b=YCWQK9Qd+hcjGBUmsFTxdKiXoTWF/cDOoQ+YLNXHNxhSfZTICsDYyI75iN/0xxQvh/ N6wCg97QQa+rxHVMBgh6PALfE4m5N8N4YViDUSofvEkZU+ARHFBOKULj9TM4Oqx+Ka23 XU2Eq6pRnn40mUposfJk9cOjRcFhGWaSSE0PBtUkYvsys4GwCMQHIO2+mLamRwUz5tzz Ya0TV7z0MppaEw/mLELNqhtYjlIRTx6qPbGOjSgrGyi0HOZzWZa5ObiaTWwhfANChZJZ DjYMcoGMcVEWlf7+DcoCqsNGJQ/atv/GQ1E0WwQqwIcj99r4pLloFJAQqf5/T9mYUsK5 Idsg== X-Gm-Message-State: APjAAAVKPNIu4LgCqq+rPifxSX4xMl8eM4SB1qyewPGoJz/6FAOYG5ys QsgBaVFVxYyNG0lddJqdA09mEufFSlSHnd3+wlM= X-Google-Smtp-Source: APXvYqwG3uo1avrcfW3J0KQARL0fzJa1WMQ1LxkjNufMYX+L2A4K8YXKD88qbrliupPRAlsGn1523r3PVSxIDslspLI= X-Received: by 2002:aa7:8750:: with SMTP id g16mr12798728pfo.190.1570135198951; Thu, 03 Oct 2019 13:39:58 -0700 (PDT) MIME-Version: 1.0 From: Stefan Kangas Date: Thu, 3 Oct 2019 22:39:47 +0200 Message-ID: Subject: Re: bug#31717: 26.1; display-line-numbers-mode enlarges indicator without need To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 31717-done Cc: Carlos Pita , 31717-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: > tags 31717 notabug > thanks > >> From: Carlos Pita >> Date: Tue, 5 Jun 2018 00:30:10 -0300 > > (Sorry for a longish response, but you raise design and implementation > issues which cannot be explained without some non-trivial background.) > >> When transitioning from line 69 to line 70 a new column is added to the >> left of the indicator as if there was a need to fit three digits despite >> that the file has less than 100 lines and despite that if it were larger >> line 100 would fall out of the window. > > Right, this is the intended behavior, and there are good reasons for > it. See below. This was tagged notabug since the observed behaviour was intentional. I'm therefore also closing it now. Best regards, Stefan Kangas ------------=_1570135262-25987-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 5 Jun 2018 02:35:27 +0000 Received: from localhost ([127.0.0.1]:33809 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQ1ok-0003dH-J5 for submit@debbugs.gnu.org; Mon, 04 Jun 2018 22:35:26 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42144) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQ1oi-0003d4-V6 for submit@debbugs.gnu.org; Mon, 04 Jun 2018 22:35:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fQ1ob-0003av-GL for submit@debbugs.gnu.org; Mon, 04 Jun 2018 22:35:19 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:35129) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fQ1ob-0003ar-Ci for submit@debbugs.gnu.org; Mon, 04 Jun 2018 22:35:17 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fQ1oX-0001ne-W2 for bug-gnu-emacs@gnu.org; Mon, 04 Jun 2018 22:35:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fQ1oQ-0003Wf-Ti for bug-gnu-emacs@gnu.org; Mon, 04 Jun 2018 22:35:12 -0400 Received: from mail-qt0-x231.google.com ([2607:f8b0:400d:c0d::231]:37196) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fQ1oQ-0003WV-Nv for bug-gnu-emacs@gnu.org; Mon, 04 Jun 2018 22:35:06 -0400 Received: by mail-qt0-x231.google.com with SMTP id q13-v6so893371qtp.4 for ; Mon, 04 Jun 2018 19:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=ZuZjTcSFP33yyUBZ1bwun90t7YRc1+no4WQmkmYRWTo=; b=FDquo5NJ8MuLmnDz+LnFoS0P/6QoxpRcDQRk8QVWbzt00XYYjbx98uDfC92IfPWnF9 4vzHxOQUcZpheQqSX3Ma3VA7VspgFZaLrF0dWJJdGjiEILWdCK4AzSqITa3SNZKbXe33 p2+monwjqN19GioU4Ek+lietA/9/c0KAnTk6OpV5CXpSKx71dQU0kJ37OBnTCN5dsoD1 qHzXtiUTuDTft/q4tGqBKlrz4F2YB1DS8nQjEWv7HkWUOtOhkF7pqNkDMxGEYOYMYEQv fRAr6HmmxzHTpMWBQ68lOiVGfju32Oh7Zj2w2fRsB76ZdomLtf4+DlvyOtjds57s3cC7 bl6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=ZuZjTcSFP33yyUBZ1bwun90t7YRc1+no4WQmkmYRWTo=; b=g0384+BvRaJV4oyy4r05hzLkYBRZRbr3rh2GCkTPIgNbEezYnFRAb5fte7W4VlbItP 4uJn613Dm9SLfzYWdp1FXZm0XdnJqZX/Rp1qPoe8PGdCxW/plx3I+0cb59izZN2Za9BT M0pZoVstkDTaHvVtEVxVentnjI7NHGS+lNWL2V9zgEZ8sF/qpMMsRCXjC5Ox6Q0QIYDG af4eGYs/L84UcA50fzNV5R8RcKHhLEZdFNhtmjsNCRnZz9vYhsUk9xFwddL2LikP2xWd qPKYM0ZJVP/6ckMlRj1h7ZK8jD4bvPofSR/z0fcqotrFrpJdmkFLWRV0jfyG9mIA8dIe 8zSA== X-Gm-Message-State: APt69E1m7MeBwU76gyCXpk3InTAqGL7l1z08QsJB0TthQhMwQTQfuxZx pMUUUWqJjIqQEp4f+ApHnlkXAQ== X-Google-Smtp-Source: ADUXVKKE7FUDXr6UQ1lI7NcASv8cCoOF1LcRw8RyeUzpb7l8B5fDs0VLBLARC99hWS4KUwUOEc0OvA== X-Received: by 2002:ac8:3338:: with SMTP id t53-v6mr22069928qta.312.1528166105791; Mon, 04 Jun 2018 19:35:05 -0700 (PDT) Received: from carlos ([190.2.33.33]) by smtp.gmail.com with ESMTPSA id t6-v6sm14839107qtn.86.2018.06.04.19.35.04 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 04 Jun 2018 19:35:05 -0700 (PDT) From: Carlos Pita To: bug-gnu-emacs@gnu.org Subject: 26.1; display-line-numbers-mode enlarges indicator without need Date: Mon, 04 Jun 2018 23:34:52 -0300 Message-ID: <87vaaym04z.fsf@carlos.i-did-not-set--mail-host-address--so-tickle-me> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) When transitioning from line 69 to line 70 a new column is added to the left of the indicator as if there was a need to fit three digits despite that the file has less than 100 lines and despite that if it were larger line 100 would fall out of the window. I have tested the transition from 969 to 970 and it shows the same effect. It's as if the mode is anticipating an extra digit soon and playing conservative. I understand that there could be performance reasons for doing this (thus avoiding the need to compute the remaining lines in a window or file) but: 1. The mode is already adding two whitespaces around the line number indicator. Wasting one more char is on the verge of infuriating ;) 2. AFAICS computing the file size doesn't seem too demanding a task, neither the remaining lines in a window (although the window could be resized). --- In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2018-05-29 built on juergen Windowing system distributor 'The X.Org Foundation', version 11.0.11906000 System Description: Manjaro Linux Recent messages: Quit [2 times] C-h C-g is undefined nil Quit Display-Line-Numbers mode disabled in current buffer x is undefined Display-Line-Numbers mode enabled in current buffer 0 (#o0, #x0, ?\C-@) scroll-down-command: Beginning of buffer [3 times] Making completion list... Configured using: 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-modules 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt' CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 MODULES THREADS LIBSYSTEMD LCMS2 Important settings: value of $LC_MONETARY: en_US.UTF-8 value of $LC_NUMERIC: en_US.UTF-8 value of $LC_TIME: en_US.UTF-8 value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Info Minor modes in effect: display-line-numbers-mode: t diff-auto-refine-mode: t pyvenv-mode: t shell-dirtrack-mode: t ido-everywhere: t winner-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t column-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils pp cl-print jka-compr vc-git display-line-numbers doom-tomorrow-night-theme doom-themes doom-themes-common cl-extra yasnippet elec-pair highlight-indentation flymake-proc flymake warnings company edmacro kmacro pcase help-fns radix-tree help-mode elpy find-file-in-project ivy delsel ivy-overlay ffap thingatpt diff-mode easy-mmode elpy-shell pyvenv esh-var esh-io esh-cmd esh-opt esh-ext esh-proc esh-arg esh-groups eshell esh-module esh-mode esh-util elpy-profile elpy-django s elpy-refactor subr-x python tramp-sh tramp tramp-compat tramp-loaddefs trampver ucs-normalize shell pcomplete parse-time format-spec advice json map ido grep compile comint ansi-color files-x etags xref project cus-edit cus-start cus-load wid-edit winner ring windmove finder-inf info package easymenu epg-config url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 395972 45995) (symbols 48 33197 1) (miscs 40 181 236) (strings 32 77765 6307) (string-bytes 1 2252569) (vectors 16 53016) (vector-slots 8 923948 18050) (floats 8 186 268) (intervals 56 4758 0) (buffers 992 16)) ------------=_1570135262-25987-1--