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

[Keith David Bershatsky <esq@lawlist.com>]

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 situa
 tions 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