GNU bug report logs - #51590
follow-mode is broken with header-line and tab-line

Previous Next

Full log

Message #106 received at 51590 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acm <at> muc.de, 51590 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#51590: follow-mode is broken with header-line and tab-line
Date: Tue, 9 Nov 2021 11:14:07 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.