bug#51590: follow-mode is broken with header-line and tab-line

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 5 Nov 2021 21:45:32 +0000
> Cc: Juri Linkov <juri@linkov.net>, 51590@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Yes.  There's a bug in posn-at-x-y, in that either the function or the
> documentation is wrong.

It isn't a bug, it is a deliberately implemented behavior.  See also
bug#15783.

> The doc says, rather unhelpfully, "By default, X and Y are relative to
> [the] text area of the selected window.".  What does "[the] text area"
> mean?

In the ELisp manual, type "i text area of a window RET" and read there.

I've now made changes there to make clear that the header-line and the
tab-line _are_ included in the text area.

> In posn-at-x-y, "the text area" _INCLUDES_ THE HEADER LINE.

Yes.  As it should.

> It would appear this behaviour of posn-at-x-y is also in Emacs 27.2.  It
> would probably be catastrophic to fix posn-at-x-y, since so many
> programs will have compensated for this bug.  So, we should probably fix
> the doc of the function.

Done on the emacs-28 branch.

> But we can fix follow-calc-win-end, by replacing the form at 2 with:
> 
>     (last-line-pos (posn-point (+ (posn-at-x-y 0 (1- ht) win)
>                                   (window-header-line-height win))))

What about the tab-line (which AFAIU was the trigger for this bug)?

> And I think we (probably me ;-) should go through the elisp manual and
> doc strings replacing vague phrases like "the text area of the window"
> with explicit descriptions involving "the header line", etc.

That'd be going overboard.  We could place a cross-reference in some
of those places to the "Frame Layout" node, though.  Suggestions for
such places are welcome.