bug#28844: 26.0.90; display-line-numbers-mode should call window-configuration-change-hook

[Paul Rankin]

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...