* 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 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 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-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-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-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-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: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
* 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
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).