* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook
@ 2017-10-15 7:56 Paul Rankin
2017-10-15 9:41 ` martin rudalics
` (2 more replies)
0 siblings, 3 replies; 27+ messages in thread
From: Paul Rankin @ 2017-10-15 7:56 UTC (permalink / raw)
To: 28844
Activating/deactivating display-line-numbers-mode alters the window configuration and so should call window-configuration-change-hook but does not.
From the Emacs NEWS file:
> Lisp programs that need to know how much screen estate is used up for
> line-number display in a window can use the new function
> 'line-number-display-width'.
This is nice, but in order to use this, we need to know when to act upon it, e.g. when display-line-numbers-mode affects the window configuration. Or, if there is a more appropriate hook.
To reproduce:
1. emacs -Q
2. add a hook to window-configuration-change-hook
3. M-x display-line-numbers-mode
Expected results:
Hook added should run when enabling display-line-numbers.
Actual results:
Hook is not run.
Configuration:
GNU Emacs 26.0.90 (build 1, x86_64-apple-darwin17.0.0) of 2017-10-15
macOS 10.13 (17A405)
MacBook Pro (Retina, 15-inch, Mid 2015)
2.2 GHz Intel Core i7
16 GB 1600 MHz DDR3
Intel Iris Pro 1536 MB
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-15 7:56 bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook Paul Rankin @ 2017-10-15 9:41 ` martin rudalics 2017-10-15 11:08 ` Paul Rankin 2017-10-22 7:20 ` Paul Rankin 2017-12-08 2:14 ` Paul Rankin 2 siblings, 1 reply; 27+ messages in thread From: martin rudalics @ 2017-10-15 9:41 UTC (permalink / raw) To: Paul Rankin, 28844 > Activating/deactivating display-line-numbers-mode alters the window > configuration and so should call window-configuration-change-hook but > does not. ‘window-configuration-change-hook’ is still run way too often, for example, when windows get resized. ‘window-size-change-functions’ might be better. But if you need such a hook, wouldn't you also need it when line numbers occupy more or less columns, for example, during scrolling? Otherwise, why can't you use ‘display-line-numbers-mode-hook’? martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-15 9:41 ` martin rudalics @ 2017-10-15 11:08 ` Paul Rankin 2017-10-15 12:12 ` martin rudalics 0 siblings, 1 reply; 27+ messages in thread From: Paul Rankin @ 2017-10-15 11:08 UTC (permalink / raw) To: martin rudalics; +Cc: 28844 On Sun, 15 Oct 2017, at 07:41 PM, martin rudalics wrote: > > Activating/deactivating display-line-numbers-mode alters the window > > configuration and so should call window-configuration-change-hook but > > does not. > > ‘window-configuration-change-hook’ is still run way too often, for > example, when windows get resized. ‘window-size-change-functions’ might > be better. But if you need such a hook, wouldn't you also need it when > line numbers occupy more or less columns, for example, during scrolling? > > Otherwise, why can't you use ‘display-line-numbers-mode-hook’? Thanks for pointing me to display-line-numbers-mode-hook, but I’ve found that it’s not enough to just check when the mode is enabled. We need to alert other concerned modes whenever display-line-numbers-mode changes the margins, e.g. due to scrolling from line 99 to 100 (which will increase the width from 2 to 3). ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-15 11:08 ` Paul Rankin @ 2017-10-15 12:12 ` martin rudalics 2017-10-15 13:27 ` Paul Rankin 2017-10-15 14:47 ` Eli Zaretskii 0 siblings, 2 replies; 27+ messages in thread From: martin rudalics @ 2017-10-15 12:12 UTC (permalink / raw) To: Paul Rankin; +Cc: 28844 >> ‘window-configuration-change-hook’ is still run way too often, for >> example, when windows get resized. ‘window-size-change-functions’ might >> be better. But if you need such a hook, wouldn't you also need it when >> line numbers occupy more or less columns, for example, during scrolling? >> >> Otherwise, why can't you use ‘display-line-numbers-mode-hook’? > > Thanks for pointing me to display-line-numbers-mode-hook, but I’ve > found that it’s not enough to just check when the mode is enabled. We > need to alert other concerned modes whenever display-line-numbers-mode > changes the margins, e.g. due to scrolling from line 99 to 100 (which > will increase the width from 2 to 3). That's what I meant when I said that "if you need such a hook, wouldn't you also need it when line numbers occupy more or less columns, for example, during scrolling?" You could use ‘window-scroll-functions’ (remembering the old line number widths) for scrolling but this would not handle simple point movements. Eli will decide what to do. If an existing hook must be chosen, I'd rather (mis-)use ‘window-size-change-functions’ - strictly spoken, display of line numbers never affects the size of windows (something which is not true vice-versa IIUC). But better, provide a separate hook like ‘line-number-width-changed-functions’ with the corresponding window as argument (and maybe the old line number width as second). martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-15 12:12 ` martin rudalics @ 2017-10-15 13:27 ` Paul Rankin 2017-10-15 14:59 ` Eli Zaretskii 2017-10-15 14:47 ` Eli Zaretskii 1 sibling, 1 reply; 27+ messages in thread From: Paul Rankin @ 2017-10-15 13:27 UTC (permalink / raw) To: martin rudalics; +Cc: 28844 On Sun, 15 Oct 2017, at 10:12 PM, martin rudalics wrote: > > Thanks for pointing me to display-line-numbers-mode-hook, but I’ve > > found that it’s not enough to just check when the mode is enabled. We > > need to alert other concerned modes whenever display-line-numbers-mode > > changes the margins, e.g. due to scrolling from line 99 to 100 (which > > will increase the width from 2 to 3). > > That's what I meant when I said that > > "if you need such a hook, wouldn't you also need it when line numbers > occupy more or less columns, for example, during scrolling?” Ah sorry Maritn. While trying the mode hook solution I forgot about your initial response! > You could use ‘window-scroll-functions’ (remembering the old line number > widths) for scrolling but this would not handle simple point movements. window-scroll-functions doesn’t quite cut it.... This is all I should have to do, where WINDOW is the selected window and MARGIN is an integer: - (set-window-margins window margin margin)) + (set-window-margins window (if (featurep 'display-line-numbers) + (- margin (line-number-display-width)) + margin) + margin)) > Eli will decide what to do. If an existing hook must be chosen, I'd > rather (mis-)use ‘window-size-change-functions’ - strictly spoken, > display of line numbers never affects the size of windows (something > which is not true vice-versa IIUC). But better, provide a separate hook > like ‘line-number-width-changed-functions’ with the corresponding window > as argument (and maybe the old line number width as second). Cool. As long as there is a hook. I appreciate inclusion of the function line-number-display-width, but introducing compatibility-breaking code then putting the onus on others to work around it is kinda rude. If there is a proper hook it eases the pain a bit. Think we can get this fixed before 26.1? I assume this might effect #28248 too... ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-15 13:27 ` Paul Rankin @ 2017-10-15 14:59 ` Eli Zaretskii 2017-10-16 3:22 ` Paul Rankin 0 siblings, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2017-10-15 14:59 UTC (permalink / raw) To: Paul Rankin; +Cc: 28844 > From: Paul Rankin <hello@paulwrankin.com> > Date: Sun, 15 Oct 2017 23:27:53 +1000 > Cc: 28844@debbugs.gnu.org > > This is all I should have to do, where WINDOW is the selected window and MARGIN is an integer: > > - (set-window-margins window margin margin)) > + (set-window-margins window (if (featurep 'display-line-numbers) > + (- margin (line-number-display-width)) > + margin) > + margin)) Exactly. So why do you need a hook? Just call this every time you need the value, and you will have the up-to-date one. > Cool. As long as there is a hook. I appreciate inclusion of the function line-number-display-width, but introducing compatibility-breaking code then putting the onus on others to work around it is kinda rude. If there is a proper hook it eases the pain a bit. If that's the problem, then you could provide a wrapper around line-number-display-width for older versions of Emacs, which would always return zero for those versions. Or even explicitly check for display-line-numbers being nil, which it always will be in older versions, and return zero even without calling line-number-display-width. I believe this is the standard way of dealing with these problems. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-15 14:59 ` Eli Zaretskii @ 2017-10-16 3:22 ` Paul Rankin 2017-10-16 4:59 ` Alex 0 siblings, 1 reply; 27+ messages in thread From: Paul Rankin @ 2017-10-16 3:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 28844 On Mon, 16 Oct 2017, at 12:59 AM, Eli Zaretskii wrote: > > From: Paul Rankin <hello@paulwrankin.com> > > Date: Sun, 15 Oct 2017 23:27:53 +1000 > > Cc: 28844@debbugs.gnu.org > > > > This is all I should have to do, where WINDOW is the selected window and MARGIN is an integer: > > > > - (set-window-margins window margin margin)) > > + (set-window-margins window (if (featurep 'display-line-numbers) > > + (- margin (line-number-display-width)) > > + margin) > > + margin)) > > Exactly. So why do you need a hook? Just call this every time you > need the value, and you will have the up-to-date one. Because this doesn’t work. If it did I wouldn’t be posting it. Think about it; your mode updates the display on its own without notifying Emacs. The basic conceptual problem is that “every time you need the value” is predicated on when display-line-numbers-mode changes the value. There’s no way for another lisp program to know when that is. > > Cool. As long as there is a hook. I appreciate inclusion of the function line-number-display-width, but introducing compatibility-breaking code then putting the onus on others to work around it is kinda rude. If there is a proper hook it eases the pain a bit. > > If that's the problem, then you could provide a wrapper around > line-number-display-width for older versions of Emacs, which would > always return zero for those versions. Or even explicitly check for > display-line-numbers being nil, which it always will be in older > versions, and return zero even without calling > line-number-display-width. I believe this is the standard way of > dealing with these problems. If you’ve introduced a problem into Emacs without the forethought on how it will adversely affect existing code, the onus is on you to either remove or fix it. Function featurep is enough to know if display-line-numbers is present (as above). ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-16 3:22 ` Paul Rankin @ 2017-10-16 4:59 ` Alex 2017-10-16 5:14 ` Paul Rankin 0 siblings, 1 reply; 27+ messages in thread From: Alex @ 2017-10-16 4:59 UTC (permalink / raw) To: Paul Rankin; +Cc: 28844 Paul Rankin <hello@paulwrankin.com> writes: > Because this doesn’t work. If it did I wouldn’t be posting it. Think about it; > your mode updates the display on its own without notifying Emacs. The basic > conceptual problem is that “every time you need the value” is predicated on when > display-line-numbers-mode changes the value. There’s no way for another lisp > program to know when that is. I agree that Emacs should present a way to specify width that automatically takes line numbers into account. > Function featurep is enough to know if display-line-numbers is present (as > above). Actually, I'd recommend (boundp 'display-line-numbers), since the feature `display-line-numbers' isn't loaded automatically in Emacs. It should be noted that `display-line-numbers-mode' is just a minor mode wrapper around the variable `display-line-numbers', which actually does the work. This also means that the hook `display-line-numbers-hook' isn't actually enough to determine whether or not line numbers have been toggled (since one can just toggle the variable instead). I'd say its main use is in user configurations. To see if line numbers are present in a buffer (and to make it compatible with older Emacsen), you should use something like: (bound-and-true-p display-line-numbers) ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-16 4:59 ` Alex @ 2017-10-16 5:14 ` Paul Rankin 2017-10-16 14:48 ` Eli Zaretskii 0 siblings, 1 reply; 27+ messages in thread From: Paul Rankin @ 2017-10-16 5:14 UTC (permalink / raw) To: Alex; +Cc: 28844 On Mon, 16 Oct 2017, at 02:59 PM, Alex wrote: > Actually, I'd recommend (boundp 'display-line-numbers), since the > feature `display-line-numbers' isn't loaded automatically in Emacs. It > should be noted that `display-line-numbers-mode' is just a minor mode > wrapper around the variable `display-line-numbers', which actually does > the work. > > This also means that the hook `display-line-numbers-hook' isn't actually > enough to determine whether or not line numbers have been toggled (since > one can just toggle the variable instead). I'd say its main use is in > user configurations. > > To see if line numbers are present in a buffer (and to make it > compatible with older Emacsen), you should use something like: > > (bound-and-true-p display-line-numbers) Sweet, thanks! I’ve encountered another bug with this mode #28855, so I think until it gets its house in order, the best thing to go with is: (if (bound-and-true-p display-line-numbers) (display-line-numbers-mode 0)) I’ve just discovered that linum-mode.el has been fixed to respect existing margins, so big love & thanks to whoever did that work. So, if linum-mode can be a good lisp citizen, so too can display-line-numbers-mode! ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-16 5:14 ` Paul Rankin @ 2017-10-16 14:48 ` Eli Zaretskii 2017-10-17 0:35 ` Paul Rankin 0 siblings, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2017-10-16 14:48 UTC (permalink / raw) To: Paul Rankin; +Cc: 28844, agrambot > From: Paul Rankin <hello@paulwrankin.com> > Cc: Eli Zaretskii <eliz@gnu.org>, 28844@debbugs.gnu.org > Date: Mon, 16 Oct 2017 15:14:10 +1000 > > > To see if line numbers are present in a buffer (and to make it > > compatible with older Emacsen), you should use something like: > > > > (bound-and-true-p display-line-numbers) Indeed, if the problem is with determining whether line-number-display-width should be called, then bound-and-true-p is the way. Sorry I didn't realize this was the issue. > Sweet, thanks! I’ve encountered another bug with this mode #28855, so I think until it gets its house in order, the best thing to go with is: > (if (bound-and-true-p display-line-numbers) (display-line-numbers-mode 0)) So does this mean the issue in this bug report (which AFAIU was how to set the window's display margins in a way that is sensitive to display-line-numbers-mode) is resolved for you? Or is there anything else to be done about this? (Bug#28855 is a separate issue, I will respond to that there.) Thanks. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-16 14:48 ` Eli Zaretskii @ 2017-10-17 0:35 ` Paul Rankin 2017-10-17 2:41 ` Eli Zaretskii 0 siblings, 1 reply; 27+ messages in thread From: Paul Rankin @ 2017-10-17 0:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 28844, agrambot On Tue, 17 Oct 2017, at 12:48 AM, Eli Zaretskii wrote: > > From: Paul Rankin <hello@paulwrankin.com> > > Cc: Eli Zaretskii <eliz@gnu.org>, 28844@debbugs.gnu.org > > Date: Mon, 16 Oct 2017 15:14:10 +1000 > > > > > To see if line numbers are present in a buffer (and to make it > > > compatible with older Emacsen), you should use something like: > > > > > > (bound-and-true-p display-line-numbers) > > Indeed, if the problem is with determining whether > line-number-display-width should be called, then bound-and-true-p is > the way. Sorry I didn't realize this was the issue. > > > Sweet, thanks! I’ve encountered another bug with this mode #28855, so I think until it gets its house in order, the best thing to go with is: > > (if (bound-and-true-p display-line-numbers) (display-line-numbers-mode 0)) > > So does this mean the issue in this bug report (which AFAIU was how to > set the window's display margins in a way that is sensitive to > display-line-numbers-mode) is resolved for you? Or is there anything > else to be done about this? (Bug#28855 is a separate issue, I will > respond to that there.) Your mode updates the display on its own without notifying Emacs. The basic conceptual problem is that “every time you need the value” is predicated on when display-line-numbers-mode changes the value. There’s no way for another lisp program to know when that is. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-17 0:35 ` Paul Rankin @ 2017-10-17 2:41 ` Eli Zaretskii 2017-10-17 4:19 ` Paul Rankin 0 siblings, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2017-10-17 2:41 UTC (permalink / raw) To: Paul Rankin; +Cc: 28844, agrambot > From: Paul Rankin <hello@paulwrankin.com> > Cc: agrambot@gmail.com, 28844@debbugs.gnu.org > Date: Tue, 17 Oct 2017 10:35:57 +1000 > > Your mode updates the display on its own without notifying Emacs. The basic conceptual problem is that “every time you need the value” is predicated on when display-line-numbers-mode changes the value. There’s no way for another lisp program to know when that is. But if you always call line-number-display-width, you don't need to know that, because that function will return the current value (which will change to reflect the changes in the space taken by line numbers). So I don't think I understand the problem, and without that I cannot think of a solution. Can you clarify the problem, please? ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-17 2:41 ` Eli Zaretskii @ 2017-10-17 4:19 ` Paul Rankin 2017-10-17 5:44 ` Eli Zaretskii 0 siblings, 1 reply; 27+ messages in thread From: Paul Rankin @ 2017-10-17 4:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 28844, agrambot On Tue, 17 Oct 2017, at 12:41 PM, Eli Zaretskii wrote: > > Your mode updates the display on its own without notifying Emacs. The basic conceptual problem is that “every time you need the value” is predicated on when display-line-numbers-mode changes the value. There’s no way for another lisp program to know when that is. > > But if you always call line-number-display-width, you don't need to > know that, because that function will return the current value (which > will change to reflect the changes in the space taken by line > numbers). > > So I don't think I understand the problem, and without that I cannot > think of a solution. Can you clarify the problem, please? Eli, you’re fundamentally misunderstanding something: 1. Your mode updates the display. 2. Another lisp program does not know your mode has updated the display. 3. Therefore, the lisp program will not know to call line-number-display-width. Your suggestion that other modes should “always” call line-number-display-width is what... to run an infinite loop waiting for your mode to furtively update the display and catch it then? ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-17 4:19 ` Paul Rankin @ 2017-10-17 5:44 ` Eli Zaretskii 2017-10-17 7:13 ` Paul Rankin 0 siblings, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2017-10-17 5:44 UTC (permalink / raw) To: Paul Rankin; +Cc: 28844, agrambot On October 17, 2017 7:19:14 AM GMT+03:00, Paul Rankin <hello@paulwrankin.com> wrote: > On Tue, 17 Oct 2017, at 12:41 PM, Eli Zaretskii wrote: > > > Your mode updates the display on its own without notifying Emacs. > The basic conceptual problem is that “every time you need the value” > is predicated on when display-line-numbers-mode changes the value. > There’s no way for another lisp program to know when that is. > > > > But if you always call line-number-display-width, you don't need to > > know that, because that function will return the current value > (which > > will change to reflect the changes in the space taken by line > > numbers). > > > > So I don't think I understand the problem, and without that I cannot > > think of a solution. Can you clarify the problem, please? > > Eli, you’re fundamentally misunderstanding something: > > 1. Your mode updates the display. > > 2. Another lisp program does not know your mode has updated the > display. > > 3. Therefore, the lisp program will not know to call > line-number-display-width. > > Your suggestion that other modes should “always” call > line-number-display-width is what... to run an infinite loop waiting > for your mode to furtively update the display and catch it then? First, let's be clear about something: it's not "my" mode. I'll never use it, except for testing and fixing bugs. I implemented this feature because line numbers are very popular among Emacs users, and existing solutions, like linum-mode, slow down Emacs, sometimes to a crawl. The excitement expressed by users on Reddit when the feature landed, which surprised me, is a clear evidence that the results are very satisfactory, as far as users are concerned. So this feature is here to stay, and Lisp packages need to adapt (bundled packages already did, AFAIK). Next, I *know* that I'm misunderstanding something, but repeating what you already said, twice, won't help me understand it. Please provide more details about your application's needs regarding the window layout. Given the little that you said until now, would checking the value returned by line-number-display-width in a post-command-hook solve your problem? If not, please tell why not, and let's take it from there. Thanks. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-17 5:44 ` Eli Zaretskii @ 2017-10-17 7:13 ` Paul Rankin 2017-10-17 8:33 ` Eli Zaretskii 2017-12-08 2:43 ` Noam Postavsky 0 siblings, 2 replies; 27+ messages in thread From: Paul Rankin @ 2017-10-17 7:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 28844, agrambot On Tue, 17 Oct 2017, at 03:44 PM, Eli Zaretskii wrote: > First, let's be clear about something: it's not "my" mode. I'll never use it, except > for testing and fixing bugs. I implemented this feature because line numbers are > very popular among Emacs users, and existing solutions, like linum-mode, slow > down Emacs, sometimes to a crawl. The excitement expressed by users on Reddit > when the feature landed, which surprised me, is a clear evidence that the results > are very satisfactory, as far as users are > concerned. So this feature is here to > stay, and Lisp packages need to adapt (bundled packages already did, AFAIK). > > Next, I *know* that I'm misunderstanding something, but repeating what you > already said, twice, won't help me understand it. Please provide more > details about your application's needs regarding the window layout. https://github.com/rnkn/olivetti Here’s the minor mode. Go nuts. > Given the little that you said until now, would checking the value returned by > line-number-display-width in a post-command-hook solve your problem? > If not, please tell why not, and let's take it from there. No it wouldn’t. I don’t need to run code after every command. Until now, the following hooks have been perfect: window-configuration-change-hook window-size-change-functions after-setting-font-hook text-scale-mode-hook n.b. window-size-change-functions only added recently due to 26.x changes. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-17 7:13 ` Paul Rankin @ 2017-10-17 8:33 ` Eli Zaretskii 2017-10-20 9:42 ` Eli Zaretskii 2017-12-08 2:43 ` Noam Postavsky 1 sibling, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2017-10-17 8:33 UTC (permalink / raw) To: Paul Rankin; +Cc: 28844, agrambot On October 17, 2017 10:13:46 AM GMT+03:00, Paul Rankin <hello@paulwrankin.com> wrote: > On Tue, 17 Oct 2017, at 03:44 PM, Eli Zaretskii wrote: > > First, let's be clear about something: it's not "my" mode. I'll > never use it, except > > for testing and fixing bugs. I implemented this feature because > line numbers are > > very popular among Emacs users, and existing solutions, like > linum-mode, slow > > down Emacs, sometimes to a crawl. The excitement expressed by users > on Reddit > > when the feature landed, which surprised me, is a clear evidence > that the results > > are very satisfactory, as far as users are > > concerned. So this feature is here to > > stay, and Lisp packages need to adapt (bundled packages already did, > AFAIK). > > > > Next, I *know* that I'm misunderstanding something, but repeating > what you > > already said, twice, won't help me understand it. Please provide > more > > details about your application's needs regarding the window layout. > > https://github.com/rnkn/olivetti > > Here’s the minor mode. Go nuts. > > > Given the little that you said until now, would checking the value > returned by > > line-number-display-width in a post-command-hook solve your problem? > > If not, please tell why not, and let's take it from there. > > No it wouldn’t. I don’t need to run code after every command. Until > now, the following hooks have been perfect: > > window-configuration-change-hook > window-size-change-functions > after-setting-font-hook > text-scale-mode-hook > > n.b. window-size-change-functions only added recently due to 26.x > changes. So having looked at your package, I think post-command-hook will solve your problem. All you need to do in the hook is check if line-number-display-width returns a value different from the last time, and if so, call your function olivetti-set-environment; otherwise do nothing. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-17 8:33 ` Eli Zaretskii @ 2017-10-20 9:42 ` Eli Zaretskii 0 siblings, 0 replies; 27+ messages in thread From: Eli Zaretskii @ 2017-10-20 9:42 UTC (permalink / raw) To: hello; +Cc: agrambot, 28844-done > Date: Tue, 17 Oct 2017 11:33:57 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 28844@debbugs.gnu.org, agrambot@gmail.com > > So having looked at your package, I think post-command-hook will solve your > problem. All you need to do in the hook is check if line-number-display-width > returns a value different from the last time, and if so, call your function > olivetti-set-environment; otherwise do nothing. Another possibility is to use pre-redisplay-function. An example is in tabulated-list.el. Anyway, since there were no further comments, I'm marking this bug done. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-17 7:13 ` Paul Rankin 2017-10-17 8:33 ` Eli Zaretskii @ 2017-12-08 2:43 ` Noam Postavsky 2017-12-08 14:48 ` Eli Zaretskii 2017-12-09 15:30 ` Paul Rankin 1 sibling, 2 replies; 27+ messages in thread From: Noam Postavsky @ 2017-12-08 2:43 UTC (permalink / raw) To: Paul Rankin; +Cc: 28844, agrambot Paul Rankin <hello@paulwrankin.com> writes: >> Given the little that you said until now, would checking the value returned by >> line-number-display-width in a post-command-hook solve your problem? >> If not, please tell why not, and let's take it from there. > > No it wouldn’t. I don’t need to run code after every command. You don't *need* to, but it would still work to run code some extra times. You just think it would be less efficient than having a dedicated hook, correct? Whereas my understanding of #20 is that Eli thinks adding a dedicated hook would be less efficient than using post-command-hook. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28844#20 PS You seem awful quick to jump to Ad Hominem, it makes resolving bug reports needlessly unpleasant. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-12-08 2:43 ` Noam Postavsky @ 2017-12-08 14:48 ` Eli Zaretskii 2017-12-09 15:30 ` Paul Rankin 1 sibling, 0 replies; 27+ messages in thread From: Eli Zaretskii @ 2017-12-08 14:48 UTC (permalink / raw) To: Noam Postavsky; +Cc: hello, 28844, agrambot > From: Noam Postavsky <npostavs@users.sourceforge.net> > Cc: Eli Zaretskii <eliz@gnu.org>, 28844@debbugs.gnu.org, agrambot@gmail.com > Date: Thu, 07 Dec 2017 21:43:29 -0500 > > Paul Rankin <hello@paulwrankin.com> writes: > > Whereas my understanding of #20 is that Eli thinks adding a dedicated > hook would be less efficient than using post-command-hook. > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28844#20 Not just less efficient, but also much more problematic for the display code as a whole from the implementation POV. > PS You seem awful quick to jump to Ad Hominem, it makes resolving bug > reports needlessly unpleasant. Well put, thanks. "Unpleasant" indeed. (I might have used stronger words here, but then I'm the one who is being attacked, so I'm probably -- what was that word? ah, yes: "biased".) More to the point, I've offered help, based on my experience in adapting other packages to this new feature. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28844#53 I'm willing to do more, and propose working code, but being unfamiliar with your package, I need some help understanding what is the expected behavior when certain display-related attributes change. For example, what should happen if the user enlarges or makes smaller the default face's font with the likes of "C-x +"? I'm asking this because the effect on the display margins is similar, so I wanted to look what the package does in that case, but it seems to do nothing: the margin dimensions are not changed as I'd expect them to. So I couldn't do more than just suggest a way to solve this. Maybe I missed some setting or knob. I actually think the problem is not so hard and could be solved quite easily, but your help, Paul, is needed to make this happen. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-12-08 2:43 ` Noam Postavsky 2017-12-08 14:48 ` Eli Zaretskii @ 2017-12-09 15:30 ` Paul Rankin 2017-12-09 16:01 ` Eli Zaretskii 1 sibling, 1 reply; 27+ messages in thread From: Paul Rankin @ 2017-12-09 15:30 UTC (permalink / raw) To: Noam Postavsky, Eli Zaretskii, 28844, agrambot I’d like to acknowledge how much of an ass I’ve been towards Eli in this thread. I’ve emailed Eli personally, but I think I owe him a public apology, and an apology to everyone else whom I made uncomfortable with my increasingly rude and condescending responses towards him. I had misinterpreted Eli’s earlier responses to me as dismissive, and thought he was biased in favour of his own code and was dismissing my concerns in order to avoid fixing something I thought was wrong/broken. I made the assumption that post-command-hook would be called many, many more times than window-configuration-change- hook, an assumption I made without testing the theory, and then continued attacking him. Now I realise he wasn’t suggesting post-command-hook as a lazy quick fix, but this would in fact improve my code. I’m sorry Eli, and everyone else in this thread. I should have shown gratitude for your help instead of such arrogance. > I'm willing to do more, and propose working code, but being unfamiliar > with your package, I need some help understanding what is the expected > behavior when certain display-related attributes change. For example, > what should happen if the user enlarges or makes smaller the default > face's font with the likes of "C-x +”? The basic idea of the package is to take a text body width value (integer or float) and keep the margins balanced on either side in each window the buffer is displayed. Whenever anything display-related changes, the package calls olivetti-set-environment. This function calls olivetti-scale-width to account for any changes to the font size. > I'm asking this because the effect on the display margins is similar, > so I wanted to look what the package does in that case, but it seems > to do nothing: the margin dimensions are not changed as I'd expect > them to. So I couldn't do more than just suggest a way to solve this. > Maybe I missed some setting or knob. I’m going to implement post-command-hook as you suggested, and once the API for line-number-display-width is locked I will call that to account for display-line-numbers. You know, the silly thing is... olivetti is designed for prose writing, most people will never use it in conjunction with line numbers... ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-12-09 15:30 ` Paul Rankin @ 2017-12-09 16:01 ` Eli Zaretskii 0 siblings, 0 replies; 27+ messages in thread From: Eli Zaretskii @ 2017-12-09 16:01 UTC (permalink / raw) To: Paul Rankin; +Cc: 28844, agrambot, npostavs > From: Paul Rankin <hello@paulwrankin.com> > Date: Sun, 10 Dec 2017 01:30:41 +1000 > > I’m sorry Eli, and everyone else in this thread. I should have shown > gratitude for your help instead of such arrogance. Thanks. > > For example, > > what should happen if the user enlarges or makes smaller the default > > face's font with the likes of "C-x +”? > > The basic idea of the package is to take a text body width value > (integer or float) and keep the margins balanced on either side in each > window the buffer is displayed. Whenever anything display-related > changes, the package calls olivetti-set-environment. This function calls > olivetti-scale-width to account for any changes to the font size. I see. This does work with "C-x +", but when I try changing the font size via mouse-appearance-menu (by clicking S-mouse-1), the margins seem to not react to the change. (I was mistaken above to ask about "C-x +", the problem is with selecting a font from the font menu.) > I’m going to implement post-command-hook as you suggested, and once the > API for line-number-display-width is locked I will call that to account > for display-line-numbers. Sounds like a good idea. Let me know if you need help in using the current line-number-display-width as part of implementing this idea. I think with the current APIs you want to call line-number-display-width with the optional argument 'columns'. This is especially important if the 'line-number' face is customized to use a font different from the one used to display the buffer text. > You know, the silly thing is... olivetti is designed for prose writing, > most people will never use it in conjunction with line numbers... I know. I myself never use line numbers, and only wrote the code because so many people do via linum.el and similar packages, and then complain that Emacs redisplay slows down too much. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-15 12:12 ` martin rudalics 2017-10-15 13:27 ` Paul Rankin @ 2017-10-15 14:47 ` Eli Zaretskii 2017-10-16 7:41 ` martin rudalics 1 sibling, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2017-10-15 14:47 UTC (permalink / raw) To: martin rudalics; +Cc: hello, 28844 > Date: Sun, 15 Oct 2017 14:12:30 +0200 > From: martin rudalics <rudalics@gmx.at> > Cc: 28844@debbugs.gnu.org > > You could use ‘window-scroll-functions’ (remembering the old line number > widths) for scrolling but this would not handle simple point movements. Simple point movements (for some value of "simple") don't affect the width used for line numbers. > Eli will decide what to do. I actually don't understand why a hook is needed. If a Lisp application wants/needs to be sensitive to the width of the line-number display, it should simply call line-number-display-width each time it needs to know the value. This function is guaranteed to return zero when display-line-numbers is nil, and it's also guaranteed (barring bugs ;-) to return the exact same value as what the display engine will use, provided that the window-start doesn't move between the call to line-number-display-width and when you need to use the value. So it will correctly reflect any changes in the width used for the line numbers. What am I missing? > If an existing hook must be chosen, I'd > rather (mis-)use ‘window-size-change-functions’ - strictly spoken, > display of line numbers never affects the size of windows (something > which is not true vice-versa IIUC). Precisely. Which IMO makes window-size-change-functions inappropriate for this purpose. > But better, provide a separate hook like > ‘line-number-width-changed-functions’ with the corresponding window > as argument (and maybe the old line number width as second). I have hard time imagining how to implement such a hook (or any hook which needs to be called "when the width changes"). You see, the display engine doesn't know that the width changed -- it computes the required width once, when it's about to redisplay a window, keeps the computed value only as long as it needs to display that window, and doesn't store it anywhere where it would survive until the next redisplay. So implementing such a hook would need some non-trivial changes, because the previous width will have to be stored in the window object, and we will need to manage that stored value (e.g., invalidate it when we switch buffers in a window). Moreover, hooks that are to be called by the display engine are usually a bad idea if they are to be used to affect redisplay, because they more often than not require an immediate additional cycle of redisplay, which makes Emacs sluggish. I provided the line-number-display-width function in the hope that it will serve any Lisp program that needs to be sensitive to the screen estate taken by line numbers. If it somehow doesn't fit this bill, please tell why, maybe it should be extended. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-15 14:47 ` Eli Zaretskii @ 2017-10-16 7:41 ` martin rudalics 0 siblings, 0 replies; 27+ messages in thread From: martin rudalics @ 2017-10-16 7:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: hello, 28844 > Simple point movements (for some value of "simple") don't affect the > width used for line numbers. Yes. I forgot that this will affect the window start position as well in all cases the OP could be interested in. > I actually don't understand why a hook is needed. If a Lisp > application wants/needs to be sensitive to the width of the > line-number display, it should simply call line-number-display-width > each time it needs to know the value. This function is guaranteed to > return zero when display-line-numbers is nil, and it's also guaranteed > (barring bugs ;-) to return the exact same value as what the display > engine will use, provided that the window-start doesn't move between > the call to line-number-display-width and when you need to use the > value. So it will correctly reflect any changes in the width used for > the line numbers. > > What am I missing? Probably nothing. IIUC your code also handles adding/removing text that would increase/decrease the line numbers width while leaving the window start position alone. martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-15 7:56 bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook Paul Rankin 2017-10-15 9:41 ` martin rudalics @ 2017-10-22 7:20 ` Paul Rankin 2017-10-22 14:27 ` Eli Zaretskii 2017-12-08 2:14 ` Paul Rankin 2 siblings, 1 reply; 27+ messages in thread From: Paul Rankin @ 2017-10-22 7:20 UTC (permalink / raw) To: 28844, eliz > Another possibility is to use pre-redisplay-function. An example is > in tabulated-list.el. I made the above changes and added to 'pre-redisplay-function but this does not work. It makes no sense to put the onus on existing working packages to endlessly fiddle to work around bugs you have introduced. Please find a solution on your end so that this bug may be closed. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-22 7:20 ` Paul Rankin @ 2017-10-22 14:27 ` Eli Zaretskii 0 siblings, 0 replies; 27+ messages in thread From: Eli Zaretskii @ 2017-10-22 14:27 UTC (permalink / raw) To: Paul Rankin; +Cc: 28844 > From: Paul Rankin <hello@paulwrankin.com> > Date: Sun, 22 Oct 2017 17:20:43 +1000 > > > Another possibility is to use pre-redisplay-function. An example is > > in tabulated-list.el. > > I made the above changes and added to 'pre-redisplay-function but this does not work. If you'd like me to look into this, please provide the details: what changes you made, and how it failed to work (including a recipe for reproducing the wrong behavior, please). I've looked at your package on GitHub, but didn't see any code related to pre-redisplay-function; apologies if I missed something. > It makes no sense to put the onus on existing working packages to endlessly fiddle to work around bugs you have introduced. If there's a bug in Emacs, sure. But I see no bug yet: the code in Emacs is working as designed, and based on adapting several bundled packages to the line-number display, my conclusion was that the existing facilities are enough to support that. Maybe your package's needs will convince me to change my mind, but for that I need to understand the problem better. And if I'm right, then making the changes to adapt your package (should you decide that such adaptations are necessary) is indeed your responsibility as the package developer. Thanks. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-10-15 7:56 bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook Paul Rankin 2017-10-15 9:41 ` martin rudalics 2017-10-22 7:20 ` Paul Rankin @ 2017-12-08 2:14 ` Paul Rankin 2017-12-08 15:22 ` Eli Zaretskii 2 siblings, 1 reply; 27+ messages in thread From: Paul Rankin @ 2017-12-08 2:14 UTC (permalink / raw) To: 28844 Eli, I understand that your blindness to this bug is probably due to your own bias. I get it, you wrote the code, you enjoyed the previously mentioned reddit upvotes for it, I understand you don’t want to admit that your code has flaws. But you need to understand that your way of seeing things is subjective and not universal. 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. 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. 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. 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. Is there anything about this that’s not clear to you? ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook 2017-12-08 2:14 ` Paul Rankin @ 2017-12-08 15:22 ` Eli Zaretskii 0 siblings, 0 replies; 27+ messages in thread From: Eli Zaretskii @ 2017-12-08 15:22 UTC (permalink / raw) To: Paul Rankin; +Cc: 28844 > From: Paul Rankin <hello@paulwrankin.com> > 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2017-12-09 16:01 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-10-15 7:56 bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook Paul Rankin 2017-10-15 9:41 ` martin rudalics 2017-10-15 11:08 ` Paul Rankin 2017-10-15 12:12 ` martin rudalics 2017-10-15 13:27 ` Paul Rankin 2017-10-15 14:59 ` Eli Zaretskii 2017-10-16 3:22 ` Paul Rankin 2017-10-16 4:59 ` Alex 2017-10-16 5:14 ` Paul Rankin 2017-10-16 14:48 ` Eli Zaretskii 2017-10-17 0:35 ` Paul Rankin 2017-10-17 2:41 ` Eli Zaretskii 2017-10-17 4:19 ` Paul Rankin 2017-10-17 5:44 ` Eli Zaretskii 2017-10-17 7:13 ` Paul Rankin 2017-10-17 8:33 ` Eli Zaretskii 2017-10-20 9:42 ` Eli Zaretskii 2017-12-08 2:43 ` Noam Postavsky 2017-12-08 14:48 ` Eli Zaretskii 2017-12-09 15:30 ` Paul Rankin 2017-12-09 16:01 ` Eli Zaretskii 2017-10-15 14:47 ` Eli Zaretskii 2017-10-16 7:41 ` martin rudalics 2017-10-22 7:20 ` Paul Rankin 2017-10-22 14:27 ` Eli Zaretskii 2017-12-08 2:14 ` Paul Rankin 2017-12-08 15:22 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).