[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#43105: (window-body-height) Reporting Too Large of Value
From: |
Stefan Kangas |
Subject: |
bug#43105: (window-body-height) Reporting Too Large of Value |
Date: |
Tue, 1 Sep 2020 07:29:58 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
tags 43105 notabug
close 43105
thanks
Eli Zaretskii <eliz@gnu.org> writes:
>> From: William Carroll <wpcarro@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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#43105: (window-body-height) Reporting Too Large of Value,
Stefan Kangas <=