bug#41737: 26.3; (window-text-pixel-size) in console

[Stefan Kangas <stefan@marxist.se>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tomas Hlavaty <tom@logand.com>
>> Date: Sat, 06 Jun 2020 14:47:14 +0200
>>
>> (window-text-pixel-size) in console seems to be wrong.
>
> I don't think it's wrong, I think the doc string needs clarification
> (which I just did).
>
>> The width seems to the width of the (visible) window.
>
> If the text is as wide or wider than the window, then by default this
> is what is expected, yes.
>
>> The height seems to be number of lines in a file.
>
> On a TTY frame, yes.
>
>> However, when evaluated in notmuch thread, the cdr of the return
>> value is a number which I cannot interpret (it is not number of
>> lines in the buffer and it is now height of the visible window).
>
> I'd need to see an example to respond to that.  But maybe using the
> new doc string (below) you will be able to understand what happens in
> that use case as well.
>
>>    Return the size of the text of WINDOW’s buffer in pixels.  WINDOW
>>    must be a live window and defaults to the selected one.  The return
>>    value is a cons of the maximum pixel-width of any text line and the
>>    maximum pixel-height of all text lines.
>>
>> I suppose that pixel in console is one character.
>
> Yes, that is a general rule in TTY frames.
>
>>    the maximum pixel-width of any text line
>>
>> but this does not seem to be true.  I have file with long line but it
>> still returns number of visible columns.
>
> Right, by default text beyond window's width is ignored.  It was not
> immediately clear from the doc string; I hope it is more clear now.
>
>>    maximum pixel-height of all text lines
>>
>> It is not clean, what does that mean and the returned number doesn't
>> seem to be useful for anything.
>
> I clarified that as well.

That was 9 weeks ago, and, given the lack of updates since, it seems
like all issues here are resolved.  I'm therefore closing this bug
report.

Best regards,
Stefan Kangas