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

[martin rudalics <rudalics@gmx.at>]

 >> 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.
 >
 > "Wrong" why, because the doc string of window-body-height mentions the
 > text area?  Or for some other reason?

If you had answered my question

   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?

I would be able to tell.  A definition like

   The @dfn{text area} of the window includes
   the header line and the tab line, if they are present in the window.

does _not_ define what the text area is.

 > And, btw, why do you use (window-body-height nil t) instead of
 > (1- (window-body-height nil t)) ?  The last pixel of the window's body
 > has Y coordinate (1- (window-body-height nil t)), no?

Right.  I wanted to be below the body.

 >> And with a bottom divider
 >>
 >> (posn-area (posn-at-x-y 0 (1- (window-pixel-height))))
 >>
 >> gets me 'bottom-divider'.
 >
 > And that is wrong why?

See above.

 >> So I'd suggest to revert your changes wrt the text area.
 >
 > I wrote in another message what I'd like to do with "text area" in doc
 > strings.  Given that they will disappear from the doc strings, what
 > other problems do you see?

That the manual still defines the "text area" and now even in a form
that lets me only guess what it is.

 >> (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
 >
 > Isn't that because window-pixel-width includes the fringes?

The header line doesn't have any fringes.

 >> 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.
 >
 > I don't think it's a bug, because window-pixel-height includes the
 > fringes, according to its doc string.  Try
 >
 >    (posn-area (posn-at-x-y
 > 	      (- (window-pixel-width) 9)
 > 	      (1- (window-pixel-height))))

The mode line doesn't have any fringes either.

martin