Please redraw when window size changes

[sten0]

Hi,

I started testing this package and noticed that it doesn't redraw when a window is resized, which leads to a horizontal ruler that is either too long or two short. What do you think about triggering a redraw using window-size-change-functions or window-configuration-change-hook?

Best,
Nicholas

[sten0]

P.S. I've read that window-configuration-change-hook might be necessary on older versions of Emacs, and I'm not sure which version introduced window-size-change-functions.

[purcell]

The code has been doing this for a long time already:

page-break-lines/page-break-lines.el

Lines 116 to 119 in 2e1d274

	(dolist (hook '(window-configuration-change-hook
	window-size-change-functions
	after-setting-font-hook
	display-line-numbers-mode-hook))

Please could you provide steps to reproduce, including your Emacs version and platform?

[sten0]

Hi Steve, Steve Purcell <notifications@github.com> writes:

The code has been doing this for a long time already: https://github.com/purcell/page-break-lines/blob/2e1d274e11071bb8daea4d6f4c0369c84466de7a/page-break-lines.el#L116-L119

I used page-break-lines 0.11, which doesn't include 2e1d274, but I've confirmed that the bug also exists on master; the outcome is appears to be identical.

Please could you provide steps to reproduce, including your Emacs version and platform?

GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.5) of 2019-09-22, modified by Debian This on Debian 10 (buster), and the specific Debian version of the emacs package `1:26.1+1-3.2+deb10u1`. Open a file with form-feed characters, activate page-break-lines, and split the frame vertically into two windows. Now click and drag the divider between windows. Window size detection appears to fail or appears to be skipped on the left-hand window. I guess it could be an emacs bug where `window-configuration-change-hook` is only being called for the right window, when the same buffer is opened in multiple frames (useful for comparing two different sections). To test this I opened two different files with form-feeds; here both 0.11 and master update both windows as expected. I also tried `global-page-break-lines-mode` on the off-chance it handled this case differently, but it didn't. So the nature of the bug is limited to case where multiple windows display the same buffer. Regards, Nicholas

[purcell]

So the nature of the bug is limited to case where multiple windows display the same buffer.

Aha. Yes, this is a "can't easily fix" issue, unfortunately: page-break-lines uses display tables to efficiently rewrite the page break char into a horizontal line, and display tables are per-buffer. If you have the same buffer in two windows with differing widths, there is no single display table that will make the line look correct in both.

In all other regards, display tables are an excellent and efficient method for implementing this package, so I'm not keen to change the code just for this relative minority case.

[sten0]

> So the nature of the bug is limited to case where multiple windows display the same buffer. Aha. Yes, this is a "can't easily fix" issue, unfortunately: `page-break-lines` uses display tables to efficiently rewrite the page break char into a horizontal line, and display tables are per-buffer. If you have the same buffer in two windows with differing widths, there is no single display table that will make the line look correct in both. In all other regards, display tables are an excellent and efficient method for implementing this package, so I'm not keen to change the code just for this relative minority case.

Oh! Thank you for taking the time to explain this :-) I agree with your rationale and believe this design decision would be a good addition to the "Issues and limitations" section of `README.md`. Would you please add it, since my PR for would just be a plagiarised/rephrased version of your explanation? ;-) The only potential workarounds for 1-display_table-per-buffer that I can think of would be something like a second (associated and/or derived) copy of the buffer that merges back to the initial buffer, but that would either add a lot of additional complexity or what would probably be a disproportionately heavy dependency. Alternatively, maybe a novel use of shadow files (built-in functionality, Emacs manual §18.3.5)?..but those don't work on Windows, and I believe that would invalidate the buffer and force a reload of buffer-copy-A whenever buffer-copy-B is saved. So yeah, I agree with your rationale because those don't seem like great potential solutions for a small mode and I'm not aware of an elegant way to monkey-patch one. Cheers, Nicholas