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

Previous Next

Full log

View this message in rfc822 format

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

>> I think "window body" and "window text area" mean the same thing, but
>> I'm not sure.
>
> They aren't.  "Text area" includes the header-line and the tab-line,
> the body doesn't.
>
>> The picture in elisp page "Basic Windows" seems to show "window body
>> height" as NOT including the header line or tab line.  That picture
>> seems to show the header line as being ABOVE the text area, not part of
>> it.
>
> The updated picture doesn't have "text area" written on it at all.

I'm afraid this is a change for the worse.  The text area does not
contain the header 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.

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 'posn-at-x-y' has a problem, let's fix it.  Just that I don't really
know what the problem is.  When, with emacs -Q, I do

(setq tab-line-format "Würstelstand ...")
(setq header-line-format "... dafür ist unser Land bekannt")

and then evaluate

(posn-point (posn-at-x-y 0 18))

it gets me nil because point is _not_ in the text area but rather
between the tab and the header line.  Digging further

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

gets me header-line here and I can't complain.

(posn-point (posn-at-x-y 0 36))

gets me 1 which is, as I'd expect, 'point-min' of *scratch*.  So where
is the problem?

martin

Previous Next

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