bug#33384: [PATCH] Fix zone.el when window is at the bottom of the buffer

[Eli Zaretskii <eliz@gnu.org>]

> From: Thomas de Beauchene <thomas.de.beauchene@gmail.com>
> Date: Sun, 18 Nov 2018 18:11:22 +0100
> 
> Oh, I'm surprised about that 2nd argument because when I try it with
> eval-expression I get values that do not make sense, usually 1 with the example
> that I provided and sometimes high values, like a hundred and some with that
> same buffer (don't remember the circumstances).

If you call window-end without the 2nd argument?  If so, it's for the
same reason, I guess: you get inaccurate values.  eval-expression
triggers a redisplay, which can make the recorded value inaccurate;
using the 2nd argument makes sure it's accurate again.

> But surprisingly when I try your fix it solves the problem. Oh man, I wanted my
> name in the commit history, but I guess it is for another time ^^'

You have your name in the history, albeit indirectly, because the
commit mentions the bug address, and anyone who will read the bug
report will see your name and your proposed solution.

> How do you explain that an overlay can, in such specific circumstances, make
> (window-end) return one more than it should be able to ?

Overlays are likely to require an extra redisplay cycle, which might
invalidate the recorded value of the window-end.

> I find it a bit puzzling, especially since when ran from
> `eval-expression` it returns nonsense with that argument. I feel
> like there is still a bug in the behaviour of (window-end) that we
> did not address here but worked around, can you confirm ?

I'm not aware of any bugs in window-end when the last argument is
non-nil, but if you can provide a recipe starting from "emacs -Q", I
will look into it.