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

[martin rudalics <rudalics@gmx.at>]

 >> The text area does not contain the header line.
 >
 > It does in my book.

How would your book describe the text area?  A T-shaped area comprising
the window's body, its header and tab line?  What would be the width of
that area?  Why would it exclude the mode line?

 >> If you look at a version of 'coordinates-in-window-p' from the past
 >> century you will see that
 >>
 >> If COORDINATES are in the text portion of WINDOW,\n\
 >>      the coordinates relative to the window are returned.\n\
 >> If they are in the mode line of WINDOW, `mode-line' is returned.\n\
 >> If they are in the top mode line of WINDOW, `header-line' is returned.\n\
 >>
 >> and this has never changed.  The text area is what window_box_height
 >> tells us.
 >
 > I don't think I understand how that follows.

Because text area and header line were mutually exclusive ever since.
At least so until last week.

 > And last-century
 > documentation may need updating anyway.

It _was_ updated continuously in a sense that tried to preserve the
original meaning of concepts and allowed them to live together with
concepts that were introduced at a later stage.  Consider the
'window-height' and 'window-width' controversy, for example.

 >> According to your change we'd now have to rewrite doc-strings and info
 >> of lots of functions like 'window-text-height', 'window-body-height' or
 >> 'window-text-pixel-size'.
 >
 > If we must, yes.  Why is that a catastrophe?

Because the person who has to do that would have to check every single
occurrence of the string "text" in all files that deal with "windows".

 >> If 'posn-at-x-y' has a problem, let's fix it.  Just that I don't really
 >> know what the problem is.
 >
 > See bug#51632.  And let's continue the discussion there.

That bug has been closed meanwhile, like the present one.  'posn-at-x-y'
is a function with ill-conceived arguments (why does WHOLE affect the X
coordinate only) and a doc-string I've never been able to understand.

   By default, X and Y are relative to text area of the selected window.
   Note that the text area includes the header-line and the tab-line of
   the window, if any of them are present.

This is at least as wrong as before: For example, with emacs -Q

(posn-area (posn-at-x-y 0 0))

gives me 'nil' here which is correct since the left fringe is not part of
the text area.  But

(posn-area (posn-at-x-y 0 (window-body-height nil t)))

gives me 'mode-line' here which is wrong since, according to your new
definition, the mode line is _not_ part of the text area.  Same holds
for a horizontal scroll bar, if present.  And with a bottom divider

(posn-area (posn-at-x-y 0 (1- (window-pixel-height))))

gets me 'bottom-divider'.

So I'd suggest to revert your changes wrt the text area.  And, since
'posn-at-x-y' deals with coordinates and not with "areas", simply say
that Y is always relative to the top edge of the window while X is
relative to the left body edge of the window if WHOLE is nil and Y is
within the top and bottom body edge of the window and relative to the
left window edge otherwise.  Do we have a deal?  Not yet ...

(posn-area (posn-at-x-y (1- (window-pixel-width)) 0))

currently gives 'nil' regardless of whether it's done with a header or
tab line and

(posn-area (posn-at-x-y
	    (1- (window-pixel-width))
	    (1- (window-pixel-height))))

gives 'nil' on the mode line.  Only when I remove _both_ fringes and the
vertical scroll bar I get the expected results.  This _is_ a bug and we
should fix it.

martin