From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#41737: 26.3; (window-text-pixel-size) in console Date: Sat, 06 Jun 2020 19:57:51 +0300 Message-ID: <83eeqs873k.fsf@gnu.org> References: <87a71g1hv1.fsf@logand.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="34945"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 41737@debbugs.gnu.org To: Tomas Hlavaty Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 06 19:55:51 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jhd2s-0008zf-O2 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Jun 2020 19:55:50 +0200 Original-Received: from localhost ([::1]:55686 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhd2r-0004x9-PU for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Jun 2020 13:55:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52914) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhd2g-0004ve-IQ for bug-gnu-emacs@gnu.org; Sat, 06 Jun 2020 13:55:38 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40854) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jhd2g-0003sN-9m for bug-gnu-emacs@gnu.org; Sat, 06 Jun 2020 13:55:38 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jhczC-0006LD-Ho for bug-gnu-emacs@gnu.org; Sat, 06 Jun 2020 13:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Jun 2020 17:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41737 X-GNU-PR-Package: emacs Original-Received: via spool by 41737-submit@debbugs.gnu.org id=B41737.159146591924353 (code B ref 41737); Sat, 06 Jun 2020 17:52:02 +0000 Original-Received: (at 41737) by debbugs.gnu.org; 6 Jun 2020 17:51:59 +0000 Original-Received: from localhost ([127.0.0.1]:52391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhcz9-0006Ki-E8 for submit@debbugs.gnu.org; Sat, 06 Jun 2020 13:51:59 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:43748) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhcz8-0006KW-9l for 41737@debbugs.gnu.org; Sat, 06 Jun 2020 13:51:58 -0400 Original-Received: from [2001:470:142:3::e] (port=34674 helo=fencepost.gnu.org) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhc90-0002kS-2I; Sat, 06 Jun 2020 12:58:06 -0400 Original-Received: from [176.228.60.248] (port=4426 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jhc8t-0003mr-6P; Sat, 06 Jun 2020 12:57:59 -0400 In-Reply-To: <87a71g1hv1.fsf@logand.com> (message from Tomas Hlavaty on Sat, 06 Jun 2020 14:47:14 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:181621 Archived-At: > From: Tomas Hlavaty > 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. The doc string now says: 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 pixel-height of all the text lines in the accessible portion of buffer text. This function exists to allow Lisp programs to adjust the dimensions of WINDOW to the buffer text it needs to display. The optional argument FROM, if non-nil, specifies the first text position to consider, and defaults to the minimum accessible position of the buffer. If FROM is t, it stands for the minimum accessible position that starts a non-empty line. TO, if non-nil, specifies the last text position and defaults to the maximum accessible position of the buffer. If TO is t, it stands for the maximum accessible position that ends a non-empty line. The optional argument X-LIMIT, if non-nil, specifies the maximum X coordinate beyond which the text should be ignored. It is therefore also the maximum width that the function can return. X-LIMIT nil or omitted means to use the pixel-width of WINDOW's body. This default means text of truncated lines wider than the window will be ignored; specify a large value for X-LIMIT if lines are truncated and you need to account for the truncated text. Use nil for X-LIMIT if you want to know how high WINDOW should become in order to fit all of its buffer's text with the width of WINDOW unaltered. Use the maximum width WINDOW may assume if you intend to change WINDOW's width. Since calculating the width of long lines can take some time, it's always a good idea to make this argument as small as possible; in particular, if the buffer contains long lines that shall be truncated anyway. The optional argument Y-LIMIT, if non-nil, specifies the maximum Y coordinate beyond which the text is to be ignored; it is therefore also the maxcomp height that the function can return (excluding the height of the mode- or header-line, if any). Y-LIMIT nil or omitted means consider all of the accessible portion of buffer text up to the position specified by TO. Since calculating the text height of a large buffer can take some time, it makes sense to specify this argument if the size of the buffer is large or unknown. Optional argument MODE-AND-HEADER-LINE nil or omitted means do not include the height of the mode- or header-line of WINDOW in the return value. If it is either the symbol `mode-line' or `header-line', include only the height of that line, if present, in the return value. If t, include the height of both, if present, in the return value.