From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Date: Thu, 26 Aug 2021 09:34:29 +0300 Message-ID: <83sfywu32i.fsf@gnu.org> References: <87eeajfvbq.fsf@telefonica.net> <83a6l7vyu2.fsf@gnu.org> <87a6l7ezks.fsf@telefonica.net> <837dgax1a0.fsf@gnu.org> <875yvug2ka.fsf@telefonica.net> <83y28qvhhn.fsf@gnu.org> <871r6ig01r.fsf@telefonica.net> <83wnoavftn.fsf@gnu.org> <87wnoaeisl.fsf@telefonica.net> <83sfyyuupx.fsf@gnu.org> <87k0k9er3w.fsf@telefonica.net> <87fsuxe9j9.fsf@telefonica.net> <83zgt5tnkh.fsf@gnu.org> <878s0pe15w.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32600"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gregory@heytings.org, 50178@debbugs.gnu.org To: =?UTF-8?Q?=C3=93scar?= Fuentes Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 26 08:35:18 2021 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 1mJ8ys-0008Bb-4f for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 26 Aug 2021 08:35:18 +0200 Original-Received: from localhost ([::1]:44216 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mJ8yq-0002HY-3J for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 26 Aug 2021 02:35:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50372) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mJ8yc-0002HP-Vp for bug-gnu-emacs@gnu.org; Thu, 26 Aug 2021 02:35:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36666) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mJ8yc-0001RU-GZ for bug-gnu-emacs@gnu.org; Thu, 26 Aug 2021 02:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mJ8yc-0000Ib-A5 for bug-gnu-emacs@gnu.org; Thu, 26 Aug 2021 02:35: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: Thu, 26 Aug 2021 06:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50178 X-GNU-PR-Package: emacs Original-Received: via spool by 50178-submit@debbugs.gnu.org id=B50178.16299596961133 (code B ref 50178); Thu, 26 Aug 2021 06:35:02 +0000 Original-Received: (at 50178) by debbugs.gnu.org; 26 Aug 2021 06:34:56 +0000 Original-Received: from localhost ([127.0.0.1]:48212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mJ8yW-0000IC-11 for submit@debbugs.gnu.org; Thu, 26 Aug 2021 02:34:56 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34248) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mJ8yU-0000I0-7Y for 50178@debbugs.gnu.org; Thu, 26 Aug 2021 02:34:54 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52310) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mJ8yO-0001BC-4x; Thu, 26 Aug 2021 02:34:48 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4353 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mJ8yN-0002Qi-Nc; Thu, 26 Aug 2021 02:34:48 -0400 In-Reply-To: <878s0pe15w.fsf@telefonica.net> (message from =?UTF-8?Q?=C3=93scar?= Fuentes on Wed, 25 Aug 2021 22:10:03 +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:212688 Archived-At: > From: Óscar Fuentes > Cc: gregory@heytings.org, 50178@debbugs.gnu.org > Date: Wed, 25 Aug 2021 22:10:03 +0200 > > Eli Zaretskii writes: > > >> Any graphics environment worth its salt has methods for measuring > >> whatever object without actually rendering it. > > > > So does Emacs: that's what window-text-pixel-size does. > > You missed the part "without actually rendering it". No, I didn't. window-text-pixel-size doesn't render the text, it _simulates_ its rendering internally. You can look at its source if you don't believe me. > As per Martin's instructions, the method for ensuring that the text does > not overflow the window is to put text on it, one line at a time, and > watch the used space (I guess that two lines would be enough to > extrapolate the space required by N lines assuming that the text is > rendered with the default font, face, etc) Martin's instructions notwithstanding, I stand by what I wrote. Yes, you need a window to compute the metrics, but that's only because some of the factors that determine the metrics can vary between windows. The window you pass to window-text-pixel-size doesn't need to be the same window where you will eventually display the text, it just should have the same window-specific parameters as the eventual one. > On the case of ido-grid-mode (which displays a grid N lines tall that > virtually expands horizontally) not knowing in advance how many lines > are available means that it must populate the mini window with some > dummy text to measure its capacity, throw away its contents and proceed > to fill the mini window with the real payload. Your conclusions are incorrect. Are you familiar with fit-window-to-buffer? Do you know that Help commands use that every time to dynamically decide how to size the window showing help? If so, doesn't the fact that this mechanism exists and works contradict your conclusions from what was said here? > >> Why that was implemented that way? (instead of using pixels, for > >> instance.) > > > > Because in most cases it's more useful: it approximates the actual > > number of lines quite well. > > Exactly, that was my point all along. And it would be a better > approximation if the display engine used that variable taking into > account line-spacing and other relevant settings which affect how the > actual text is rendered. I said "in most cases". It is impossible to do that in all cases. The case you are talking about is one of the rare exceptions.