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#48095: 28.0.50; display-line-numbers-mode / display-line-numbers-width-start incorrect Date: Fri, 30 Apr 2021 10:36:45 +0300 Message-ID: <83czuccjg2.fsf@gnu.org> References: <83pmydea3b.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9698"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 48095-done@debbugs.gnu.org To: Len Trigg Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 30 09:38:28 2021 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 1lcNjH-0002QY-Qb for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Apr 2021 09:38:27 +0200 Original-Received: from localhost ([::1]:40070 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcNjG-0002Ga-RN for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Apr 2021 03:38:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56820) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lcNis-00027a-Vj for bug-gnu-emacs@gnu.org; Fri, 30 Apr 2021 03:38:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45842) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lcNis-0006oq-Lv for bug-gnu-emacs@gnu.org; Fri, 30 Apr 2021 03:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lcNis-0004AA-IB for bug-gnu-emacs@gnu.org; Fri, 30 Apr 2021 03:38:02 -0400 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 Apr 2021 07:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 48095 X-GNU-PR-Package: emacs Mail-Followup-To: 48095@debbugs.gnu.org, eliz@gnu.org, lenbok@gmail.com Original-Received: via spool by 48095-done@debbugs.gnu.org id=D48095.161976822415930 (code D ref 48095); Fri, 30 Apr 2021 07:38:02 +0000 Original-Received: (at 48095-done) by debbugs.gnu.org; 30 Apr 2021 07:37:04 +0000 Original-Received: from localhost ([127.0.0.1]:57387 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcNhw-00048s-J9 for submit@debbugs.gnu.org; Fri, 30 Apr 2021 03:37:04 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48402) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcNhu-00048M-N4 for 48095-done@debbugs.gnu.org; Fri, 30 Apr 2021 03:37:03 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58517) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcNhp-0006E5-Fu; Fri, 30 Apr 2021 03:36:57 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3726 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lcNhm-0000Kb-K7; Fri, 30 Apr 2021 03:36:57 -0400 In-Reply-To: (message from Len Trigg on Fri, 30 Apr 2021 10:29:23 +1200) 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" Xref: news.gmane.io gmane.emacs.bugs:205229 Archived-At: > From: Len Trigg > Date: Fri, 30 Apr 2021 10:29:23 +1200 > Cc: 48095@debbugs.gnu.org > > That seems to work perfectly for my goal (and I assume the intent of display-line-numbers-width-start) of > having the width stay fixed unless content gets added to the buffer. It might help to add guidance in the docs > that extra lines would typically be set to the maximum window height. Thanks, I added that to the doc string. > Or maybe that value could instead be > automatically computed from the height of the tallest emacs frame at that time? I assume that's not too > intensive to determine since it happens once when the mode is activated? This would be over-engineering, IMO. First, some people tend to have lots of frames, so this might be expensive. Second, what matters is not the frame height but the window height, and we could have many windows even if the number of frames is small. Third, some frames and windows could be dedicated to special displays, and thus not really relevant (example: Speedbar frames), so we will no doubt be asked to provide yet another defcustom, to let users control which frames are exempt from accounting for their height. So I think asking users to provide a value strikes a good balance between functionality and complexity, at least unless we hear about use cases where automatic adjustment would really make a lot of sense. With that in mind, I installed the change on the master branch, and I'm closing this bug report.