From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook Date: Fri, 08 Dec 2017 17:22:35 +0200 Message-ID: <837etxw8g4.fsf@gnu.org> References: <1512699242.3658603.1198014544.7EB49FB0@webmail.messagingengine.com> 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 1512746655 15766 195.159.176.226 (8 Dec 2017 15:24:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 8 Dec 2017 15:24:15 +0000 (UTC) Cc: 28844@debbugs.gnu.org To: Paul Rankin Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 08 16:24:07 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 1eNKVS-0003mQ-32 for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Dec 2017 16:24:06 +0100 Original-Received: from localhost ([::1]:37752 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eNKVZ-0001KY-7k for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Dec 2017 10:24:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58519) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eNKVT-0001Fi-Bw for bug-gnu-emacs@gnu.org; Fri, 08 Dec 2017 10:24:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eNKVO-0007qj-Jw for bug-gnu-emacs@gnu.org; Fri, 08 Dec 2017 10:24:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44013) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eNKVO-0007qU-Fw for bug-gnu-emacs@gnu.org; Fri, 08 Dec 2017 10:24:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eNKVO-0001ai-9v for bug-gnu-emacs@gnu.org; Fri, 08 Dec 2017 10:24:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Dec 2017 15:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28844 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28844-submit@debbugs.gnu.org id=B28844.15127465946062 (code B ref 28844); Fri, 08 Dec 2017 15:24:02 +0000 Original-Received: (at 28844) by debbugs.gnu.org; 8 Dec 2017 15:23:14 +0000 Original-Received: from localhost ([127.0.0.1]:52694 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eNKUa-0001Zh-P6 for submit@debbugs.gnu.org; Fri, 08 Dec 2017 10:23:14 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:39125) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eNKUY-0001ZT-Rf for 28844@debbugs.gnu.org; Fri, 08 Dec 2017 10:23:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eNKUP-0006xc-2M for 28844@debbugs.gnu.org; Fri, 08 Dec 2017 10:23:05 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40279) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eNKUO-0006xX-U9; Fri, 08 Dec 2017 10:23:00 -0500 Original-Received: from [176.228.60.248] (port=3213 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eNKUN-00065y-F3; Fri, 08 Dec 2017 10:23:00 -0500 In-reply-to: <1512699242.3658603.1198014544.7EB49FB0@webmail.messagingengine.com> (message from Paul Rankin on Fri, 08 Dec 2017 12:14:02 +1000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:140818 Archived-At: > From: Paul Rankin > Cc: eliz@gnu.org > Date: Fri, 08 Dec 2017 12:14:02 +1000 > > The bug is that when the user scrolls up or down, past a point where the width of the line numbers changes from e.g. 99 to the number width from 2 to 3 thus making the width of line number display change from 4 to 5, display-line-numbers-mode necessarily changes the window display configuration to accommodate this character. > > However, display-line-numbers-mode doesn’t appear to tell the rest of Emacs about this change, so even if we all wanted to accommodate your display changes, as far as I can tell, we cannot. Nevertheless modes like tabulated-list-mode, the list-packages display based on it, and others have been adapted to this new feature. Which means that doing so is not only possible, it is also relatively easy. Your mode needs to do something similar. I'm willing to help if you answer a few questions, so I understand the expectations of your users better than I do now. > It’s nice that you added the token function line-number-display-width, but aside from the bug with its return value being off by 2 (#29597), this function is not useful unless other lisp programs know *when* to call it. You are wrong here on both counts: the value of 2 is not a bug (see how display-line-numbers.el uses this if you want to understand the details); and the function is useful enough to be the basis for all the adaptations I did in core Emacs features (some of them are mentioned above). I'm quite sure this function will also allow to adapt your package to this feature. A little cooperation from you is all that is required. We could already have this solved, if we hadn't wasted time on these futile arguments. > The easiest solution, the one that baffles me why you haven’t just included already rather than continue to argue with me, is that when display-line-numbers-mode changes the window, you run window-configuration-change-hook. I explained why this would be a bad idea in several related discussions. I invite you to read them, if you want to understand my reasons better, and I'm willing to answer further questions regarding those issues. Of course, you don't _need_ to read those discussions and/or dig into the related code and understand it, if you don't want to. You could instead simply trust me when I say, based on some years of hacking the Emacs display code: THIS IS A BAD IDEA! So bad that if someone wants to implement it against my best judgment, they will need to do that over my dead body. > If, for some Eli-reason, you don’t want to run window-configuration-change-hook, you can add a simple hook, which gets run whenever display-line-numbers-mode needs to change the window configuration. Then other lisp programs can call line-number-display-width, and provided its bug gets fixed and it returns the correct width, everyone is happy. See above: you are talking out of lack of knowledge. You don't know and don't understand how this feature works, how it plugs into the Emacs display code, and therefore cannot appreciate what havoc will be caused by running any such hooks when line numbers are being rendered. I do understand all that stuff, and that is why I'm opposed to doing it. And based on my experience of adapting several Emacs features to the line-number display, I can be confident that such a hook is not needed, that existing APIs, including line-number-display-width, are enough. > Is there anything about this that’s not clear to you? The only thing that is not clear to me is why do you prefer to attack me personally instead of trying to adapt your package to Emacs development. Don't you want your package to be used by many people who like line numbers in their buffers? Then please drop the attitude, and let's instead work together to make those adaptations.