bug#18618: 25.0.50; `window-end win t` produces erroenous result with `window-scroll-functions` hook.

[Keith David Bershatsky]

Lars:

I haven't played in depth with the Emacs internals for a couple of years or so. 
 In working on my own feature requests (back in the day), I learned that 
window-start/end cannot be accurately ascertained with 100% certainty until the 
tail end of redisplay ...  If a user were to add/remove something with Lisp, 
then redisplay would need to recalculate to take that modification into 
consideration -- necessitating further recalculation, which may alter 
window-start/end.

In terms of my own feature requests, I opted to use `update_window` in 
dispnew.c to add visual modifications to the glass that did not alter any text 
or points in the buffer.  That way, no further calculation was needed as to 
window-start/end points -- as said points were "final" calculations at that 
late stage of redisplay.  The `window-scroll-functions` hook only operates 
under certain criteria, but not all the time.  As of my last look a couple of 
years ago, there was no hook that operated towards the latter part of redisplay 
with 100% certainty.  For a few years before using `update_window`, I used a 
combination of the `post-command-hook` and the `window-scroll-functions` hook 
to try and catch the majority of situations to ascertain window-start/end, but 
there were always several situations where the two hooks where insufficient ... 
 An example of what users were required to do back in the day can be seen by 
examining libraries such as the deprecated linum-mode, which used both o
 f the aforementioned hooks because there is/was no sole hook that could 
accurately predict window-start/end with 100% certainty.

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

> Date: [05-28-2021 20:37:18] <29 May 2021 05:37:18 +0200>
> From: Lars Ingebrigtsen <larsi@gnus.org>
> To: Keith David Bershatsky <esq@lawlist.com>
> Cc: 18618@debbugs.gnu.org
> Subject: Re: bug#18618: 25.0.50; `window-end win t` produces erroenous result 
> with `window-scroll-functions` hook.
> 
> Keith David Bershatsky <esq@lawlist.com> writes:
> 
> > Steps to reproduce the issue.
> >
> > 1.  Create a function that reports (e.g., a message) the value of 
> > `(window-end win t)` and attach that function to the 
> > `window-scroll-functions` hook.
> >
> > 2.  Open a long file in either fundamental-mode or text-mode.
> >
> > 3.  M-x end-of-buffer
> >
> > 4.  M-x beginning-of-buffer
> >
> > The result of step 4 reports an erroneous window-end value that is at
> > the very end of the buffer, instead of the correct window-end (i.e.,
> > which is much closer to the beginning of the buffer).
> 
> (I'm going through old bug reports that unfortunately got no response at
> the time.)
> 
> This problem is still present in Emacs 28.  Here's an easier test case:
> 
> (defun foo (win _)
>   (message "End: %s" (window-end win t))
>   nil)
> (push 'foo window-scroll-functions)
> 
> This reports the same number in both 3) and 4) when transient-mark-mode
> is switched on, but not when it's off.  It's also correct if that mode
> is on, and the region is active.
> 
> I haven't tried to debug further -- perhaps it's immediately obvious to
> somebody what could be causing this glitch?
> 
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no