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: Sat, 06 Nov 2021 20:40:41 +0200

> Cc: 51590@debbugs.gnu.org, juri@linkov.net
> From: martin rudalics <rudalics@gmx.at>
> Date: Sat, 6 Nov 2021 19:31:11 +0100
> 
>  >> 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.

I respectfully disagree.

> The text area does not contain the header line.

It does in my book.

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

I don't think I understand how that follows.  And last-century
documentation may need updating anyway.

> 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 we must, yes.  Why is that a catastrophe?

> If 'posn-at-x-y' has a problem, let's fix it.  Just that I don't really
> know what the problem is.

See bug#51632.  And let's continue the discussion there.





reply via email to

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