GNU bug report logs - #41737
26.3; (window-text-pixel-size) in console

Previous Next

Full log

Message #13 received at 41737-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 41737-done <at> debbugs.gnu.org, Tomas Hlavaty <tom <at> logand.com>
Subject: Re: bug#41737: 26.3; (window-text-pixel-size) in console
Date: Wed, 12 Aug 2020 18:01:31 -0700

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

>> From: Tomas Hlavaty <tom <at> 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

Previous Next

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