bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#51590: follow-mode is broken with header-line and tab-line
Date: Mon, 08 Nov 2021 20:47:09 +0200

> Cc: acm@muc.de, 51590@debbugs.gnu.org, juri@linkov.net
> From: martin rudalics <rudalics@gmx.at>
> Date: Mon, 8 Nov 2021 16:36:36 +0100
> 
>    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.

"Wrong" why, because the doc string of window-body-height mentions the
text area?  Or for some other reason?

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?

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

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

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

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]