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

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> linkov.net>

Date: Wed, 3 Nov 2021 18:28:01 UTC

Severity: normal

Merged with 47498

Found in version 28.0.50

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: acm <at> muc.de, 51590 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: bug#51590: follow-mode is broken with header-line and tab-line
Date: Mon, 08 Nov 2021 20:47:09 +0200
> Cc: acm <at> muc.de, 51590 <at> debbugs.gnu.org, juri <at> linkov.net
> From: martin rudalics <rudalics <at> 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))))




This bug report was last modified 3 years and 199 days ago.

Previous Next


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