GNU bug report logs - #43105
(window-body-height) Reporting Too Large of Value

Previous Next

Package: emacs;

Reported by: William Carroll <wpcarro <at> gmail.com>

Date: Sat, 29 Aug 2020 18:07:01 UTC

Severity: normal

Tags: notabug

Done: Stefan Kangas <stefan <at> marxist.se>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43105 in the body.
You can then email your comments to 43105 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#43105; Package emacs. (Sat, 29 Aug 2020 18:07:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to William Carroll <wpcarro <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 29 Aug 2020 18:07:02 GMT) Full text and rfc822 format available.

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

From: William Carroll <wpcarro <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: (window-body-height) Reporting Too Large of Value
Date: Sat, 29 Aug 2020 18:10:17 +0100
[Message part 1 (text/plain, inline)]
I believe `(window-body-height)` does not account for non-zero
`line-spacing` amounts. This causes `(window-body-height)` in graphical
Emacs to report values larger than the number of lines of text that can
render on the screen.

This affects programs like vterm.el and others that rely on
`(window-body-height)`. In my particular case, when I ran `man` and `less`
from vterm.el, it rendered things above the top "fold" of the screen.

When I tried to reproduce these issues with `emacs -nw`, everything was
fine. I imagine this is because `emacs -nw` disregards `line-spacing`.

I'm happy to share more information to help someone reproduce this issue.
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43105; Package emacs. (Sat, 29 Aug 2020 18:38:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: William Carroll <wpcarro <at> gmail.com>
Cc: 43105 <at> debbugs.gnu.org
Subject: Re: bug#43105: (window-body-height) Reporting Too Large of Value
Date: Sat, 29 Aug 2020 21:37:19 +0300
> From: William Carroll <wpcarro <at> gmail.com>
> Date: Sat, 29 Aug 2020 18:10:17 +0100
> 
> I believe `(window-body-height)` does not account for non-zero `line-spacing` amounts. This causes
> `(window-body-height)` in graphical Emacs to report values larger than the number of lines of text that can
> render on the screen.

window-body-height reports the height of the window's body in units of
canonical character height:

  If PIXELWISE is nil, return the largest integer smaller than WINDOW’s
  pixel height divided by the character height of WINDOW’s frame.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Thus, window-body-height is by design insensitive to factors like
non-default fonts, line-spacing, etc.

> This affects programs like vterm.el and others that rely on `(window-body-height)`. In my particular case,
> when I ran `man` and `less` from vterm.el, it rendered things above the top "fold" of the screen.

Then the bug is in vterm.el: it should use other APIs to get the
dimensions in terms of actual number of lines in the window.  The
function window-body-height works as intended.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43105; Package emacs. (Tue, 01 Sep 2020 14:31:02 GMT) Full text and rfc822 format available.

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43105 <at> debbugs.gnu.org, William Carroll <wpcarro <at> gmail.com>
Subject: Re: bug#43105: (window-body-height) Reporting Too Large of Value
Date: Tue, 1 Sep 2020 07:29:58 -0700
tags 43105 notabug
close 43105
thanks

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: William Carroll <wpcarro <at> gmail.com>
>> Date: Sat, 29 Aug 2020 18:10:17 +0100
>>
>> I believe `(window-body-height)` does not account for non-zero `line-spacing` amounts. This causes
>> `(window-body-height)` in graphical Emacs to report values larger than the number of lines of text that can
>> render on the screen.
>
> window-body-height reports the height of the window's body in units of
> canonical character height:
>
>   If PIXELWISE is nil, return the largest integer smaller than WINDOW’s
>   pixel height divided by the character height of WINDOW’s frame.
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Thus, window-body-height is by design insensitive to factors like
> non-default fonts, line-spacing, etc.
>
>> This affects programs like vterm.el and others that rely on `(window-body-height)`. In my particular case,
>> when I ran `man` and `less` from vterm.el, it rendered things above the top "fold" of the screen.
>
> Then the bug is in vterm.el: it should use other APIs to get the
> dimensions in terms of actual number of lines in the window.  The
> function window-body-height works as intended.

I'm therefore closing this bug report.




Added tag(s) notabug. Request was from Stefan Kangas <stefan <at> marxist.se> to control <at> debbugs.gnu.org. (Tue, 01 Sep 2020 14:31:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 43105 <at> debbugs.gnu.org and William Carroll <wpcarro <at> gmail.com> Request was from Stefan Kangas <stefan <at> marxist.se> to control <at> debbugs.gnu.org. (Tue, 01 Sep 2020 14:31:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 30 Sep 2020 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 264 days ago.

Previous Next


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