From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Resent-From: =?UTF-8?Q?=C3=93scar?= Fuentes Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Aug 2021 02:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 50178 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 50178@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.162977093930977 (code B ref -1); Tue, 24 Aug 2021 02:09:02 +0000 Received: (at submit) by debbugs.gnu.org; 24 Aug 2021 02:08:59 +0000 Received: from localhost ([127.0.0.1]:42852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mILrz-00083W-D0 for submit@debbugs.gnu.org; Mon, 23 Aug 2021 22:08:59 -0400 Received: from lists.gnu.org ([209.51.188.17]:41704) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mILru-00083M-Sr for submit@debbugs.gnu.org; Mon, 23 Aug 2021 22:08:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42368) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mILru-0000Bz-C4 for bug-gnu-emacs@gnu.org; Mon, 23 Aug 2021 22:08:50 -0400 Received: from relayout03.e.movistar.es ([86.109.101.203]:36995 helo=relayout03-redir.e.movistar.es) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mILrr-0008M4-NZ for bug-gnu-emacs@gnu.org; Mon, 23 Aug 2021 22:08:49 -0400 Received: from sky (14.red-79-145-70.dynamicip.rima-tde.net [79.145.70.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout03.e.movistar.es (Postfix) with ESMTPSA id 4GtswT4xYQzMksW for ; Tue, 24 Aug 2021 04:08:41 +0200 (CEST) From: =?UTF-8?Q?=C3=93scar?= Fuentes Date: Tue, 24 Aug 2021 04:08:41 +0200 Message-ID: <87eeajfvbq.fsf@telefonica.net> MIME-Version: 1.0 Content-Type: text/plain X-TnetOut-Country: IP: 79.145.70.14 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout03 X-TnetOut-MsgID: 4GtswT4xYQzMksW.A068A X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1630375722.51984@VfOD/ML5UnJHathhgt9Wvw X-Spam-Status: No Received-SPF: softfail client-ip=86.109.101.203; envelope-from=ofv@wanadoo.es; helo=relayout03-redir.e.movistar.es X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Seems that on some circunstances the vertical space calculated for the text on the echo area does not account for the value of line-spacing: emacs -Q M-x icomplete-vertical-mode M-x fido-mode (set-default 'line-spacing 0.1) Now M-x will display a list of candidates with the last candidate partially visible for lack of vertical space. In GNU Emacs 28.0.50 (build 4, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0) of 2021-07-30 built on sky Repository revision: d9bc7dbefd88995d04b9843f521d82118265fecf Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: Debian GNU/Linux 11 (bullseye) Configured using: 'configure --with-native-compilation --without-toolkit-scroll-bars --with-x-toolkit=lucid --with-modules --without-imagemagick build_alias= host_alias= target_alias=' Configured features: CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBOTF LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF X11 XAW3D XDBE XIM XPM LUCID ZLIB From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Aug 2021 11:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50178 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: 50178@debbugs.gnu.org Received: via spool by 50178-submit@debbugs.gnu.org id=B50178.162980632326783 (code B ref 50178); Tue, 24 Aug 2021 11:59:01 +0000 Received: (at 50178) by debbugs.gnu.org; 24 Aug 2021 11:58:43 +0000 Received: from localhost ([127.0.0.1]:43365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIV4k-0006xu-Sm for submit@debbugs.gnu.org; Tue, 24 Aug 2021 07:58:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60874) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIV4i-0006xg-RY for 50178@debbugs.gnu.org; Tue, 24 Aug 2021 07:58:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33026) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mIV4c-0007q7-V9; Tue, 24 Aug 2021 07:58:34 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2718 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 1mIV4c-0006tn-Ex; Tue, 24 Aug 2021 07:58:34 -0400 Date: Tue, 24 Aug 2021 14:58:29 +0300 Message-Id: <83a6l7vyu2.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87eeajfvbq.fsf@telefonica.net> (message from =?UTF-8?Q?=C3=93scar?= Fuentes on Tue, 24 Aug 2021 04:08:41 +0200) References: <87eeajfvbq.fsf@telefonica.net> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Óscar Fuentes > Date: Tue, 24 Aug 2021 04:08:41 +0200 > > Seems that on some circunstances the vertical space calculated for the > text on the echo area does not account for the value of line-spacing: > > emacs -Q > M-x icomplete-vertical-mode > M-x fido-mode > (set-default 'line-spacing 0.1) > > Now M-x will display a list of candidates with the last candidate > partially visible for lack of vertical space. And why is that a problem? Emacs displays partially visible lines at end of window in many cases; as long as the list of completion candidates is long enough, you cannot see all of them anyway. Or maybe you have a specific recipe in mind where this works incorrectly, in which case please show that recipe. Thanks. From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Resent-From: =?UTF-8?Q?=C3=93scar?= Fuentes Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Aug 2021 13:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50178 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 50178@debbugs.gnu.org Received: via spool by 50178-submit@debbugs.gnu.org id=B50178.16298120803989 (code B ref 50178); Tue, 24 Aug 2021 13:35:01 +0000 Received: (at 50178) by debbugs.gnu.org; 24 Aug 2021 13:34:40 +0000 Received: from localhost ([127.0.0.1]:43454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIWZb-00012G-Pc for submit@debbugs.gnu.org; Tue, 24 Aug 2021 09:34:40 -0400 Received: from relayout03.e.movistar.es ([86.109.101.203]:46183 helo=relayout03-redir.e.movistar.es) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIWZW-00011z-EJ for 50178@debbugs.gnu.org; Tue, 24 Aug 2021 09:34:38 -0400 Received: from sky (14.red-79-145-70.dynamicip.rima-tde.net [79.145.70.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout03.e.movistar.es (Postfix) with ESMTPSA id 4Gv97m3hLXzMlVX; Tue, 24 Aug 2021 15:34:28 +0200 (CEST) From: =?UTF-8?Q?=C3=93scar?= Fuentes References: <87eeajfvbq.fsf@telefonica.net> <83a6l7vyu2.fsf@gnu.org> Date: Tue, 24 Aug 2021 15:34:27 +0200 In-Reply-To: <83a6l7vyu2.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 24 Aug 2021 14:58:29 +0300") Message-ID: <87a6l7ezks.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TnetOut-Country: IP: 79.145.70.14 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout03 X-TnetOut-MsgID: 4Gv97m3hLXzMlVX.A945F X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1630416868.8487@GTdei1DHjo9o1heVkBmQGg X-Spam-Status: No X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: > And why is that a problem? Emacs displays partially visible lines at > end of window in many cases; as long as the list of completion > candidates is long enough, you cannot see all of them anyway. > > Or maybe you have a specific recipe in mind where this works > incorrectly, in which case please show that recipe. There are some packages that works displaying a certain number of lines on the echo area (ido-grid-mode, for instance.) They set max-mini-window-height to an integer and expect that Emacs will take care of resizing the echo area accordingly, if possible. If the resulting echo area is not tall enough, there is a problem. IMO max-mini-window-height, when set to an integer, should mean "I want this many lines", as it does when line-spacing is nil. Otherwise every one of those packages must implement the heuristics for taking into account `line-spacing' and any other present and future variable that might affect the number of lines visible on the echo area. From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Aug 2021 16:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50178 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: 50178@debbugs.gnu.org Received: via spool by 50178-submit@debbugs.gnu.org id=B50178.162982204530353 (code B ref 50178); Tue, 24 Aug 2021 16:21:02 +0000 Received: (at 50178) by debbugs.gnu.org; 24 Aug 2021 16:20:45 +0000 Received: from localhost ([127.0.0.1]:45086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIZAH-0007tK-G2 for submit@debbugs.gnu.org; Tue, 24 Aug 2021 12:20:45 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37332) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIZAC-0007sw-0l for 50178@debbugs.gnu.org; Tue, 24 Aug 2021 12:20:40 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42852) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mIZA6-0001Ei-7C; Tue, 24 Aug 2021 12:20:30 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3068 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 1mIZA5-0006y1-QK; Tue, 24 Aug 2021 12:20:30 -0400 Date: Tue, 24 Aug 2021 19:20:23 +0300 Message-Id: <837dgax1a0.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87a6l7ezks.fsf@telefonica.net> (message from =?UTF-8?Q?=C3=93scar?= Fuentes on Tue, 24 Aug 2021 15:34:27 +0200) References: <87eeajfvbq.fsf@telefonica.net> <83a6l7vyu2.fsf@gnu.org> <87a6l7ezks.fsf@telefonica.net> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Óscar Fuentes > Cc: 50178@debbugs.gnu.org > Date: Tue, 24 Aug 2021 15:34:27 +0200 > > There are some packages that works displaying a certain number of lines > on the echo area (ido-grid-mode, for instance.) They set > max-mini-window-height to an integer and expect that Emacs will take > care of resizing the echo area accordingly, if possible. If the > resulting echo area is not tall enough, there is a problem. > > IMO max-mini-window-height, when set to an integer, should mean "I want > this many lines", as it does when line-spacing is nil. But that's not the exact meaning of the value of that variable. The doc string says: If an integer, it specifies the maximum height in units of the mini-window frame’s default font’s height. ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ It is measured in units of the canonical character height, and that doesn't take the line-spacing into account, like it doesn't take into account faces that change the font or the size of the characters. IOW, the value means "this many lines", but assuming that the line's height is the one you get with the frame's default font. You get the same in a window other than mini-window: if you set line-spacing, chances are the last screen line will be only partially visible. Why should the mini-window be different? it's just another window. So once again, I see no problem here, it's just Emacs display working as designed in the face of variable-size fonts and window heights that aren't necessarily an integral multiple of the font/line height. From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Resent-From: =?UTF-8?Q?=C3=93scar?= Fuentes Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Aug 2021 17:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50178 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 50178@debbugs.gnu.org Received: via spool by 50178-submit@debbugs.gnu.org id=B50178.162982708615125 (code B ref 50178); Tue, 24 Aug 2021 17:45:01 +0000 Received: (at 50178) by debbugs.gnu.org; 24 Aug 2021 17:44:46 +0000 Received: from localhost ([127.0.0.1]:45136 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIaTe-0003vt-8U for submit@debbugs.gnu.org; Tue, 24 Aug 2021 13:44:46 -0400 Received: from relayout02.e.movistar.es ([86.109.101.202]:63809 helo=relayout02-redir.e.movistar.es) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIaTc-0003ve-FK for 50178@debbugs.gnu.org; Tue, 24 Aug 2021 13:44:45 -0400 Received: from sky (14.red-79-145-70.dynamicip.rima-tde.net [79.145.70.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout02.e.movistar.es (Postfix) with ESMTPSA id 4GvGhP5W2szdZT2; Tue, 24 Aug 2021 19:44:37 +0200 (CEST) From: =?UTF-8?Q?=C3=93scar?= Fuentes References: <87eeajfvbq.fsf@telefonica.net> <83a6l7vyu2.fsf@gnu.org> <87a6l7ezks.fsf@telefonica.net> <837dgax1a0.fsf@gnu.org> Date: Tue, 24 Aug 2021 19:44:37 +0200 In-Reply-To: <837dgax1a0.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 24 Aug 2021 19:20:23 +0300") Message-ID: <875yvug2ka.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-TnetOut-Country: IP: 79.145.70.14 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout02 X-TnetOut-MsgID: 4GvGhP5W2szdZT2.A880A X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1630431878.17986@QK6Lgy470XWDN/X7LGmJnA X-Spam-Status: No X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: >> IMO max-mini-window-height, when set to an integer, should mean "I want >> this many lines", as it does when line-spacing is nil. > > But that's not the exact meaning of the value of that variable. The > doc string says: > > If an integer, it specifies the maximum height in units of the > mini-window frame=E2=80=99s default font=E2=80=99s height. ^^^^^^^^= ^^^^^^^ > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > It is measured in units of the canonical character height, and that > doesn't take the line-spacing into account, like it doesn't take into > account faces that change the font or the size of the characters. > > IOW, the value means "this many lines", but assuming that the line's > height is the one you get with the frame's default font. IMAO the case where the user wants to ensure that the mini window is capable of displaying at least X lines is much more common than the user wanting a height of at least X times the default font's height. Crucially, the first case is about showing information, while the second is about aesthetics (suppossing that it is used at all with that intention.) I suspect that max-mini-window-height was introduced with the former use case in mind, but was not updated when line-spacing was implemented later. If we have no method for ensuring that the echo area is capable of displaying at least X lines (within some reasonable limits) then we need one. > You get the same in a window other than mini-window: if you set > line-spacing, chances are the last screen line will be only partially > visible. Why should the mini-window be different? it's just another > window. You can't navigate around on the contents of the mini-window. If a package can't rely on setting max-mini-window-height for showing certain number of lines on the mini-window, then it must implement vertical scrolling, which makes things complex both on the programming side and on the UI side, just to make sure that the user can access the content's of the overflowing line(s), if any. The case of ido-grid-mode is glaring: it has a defcustom for setting how many lines to show. When the command is invoked, it sets max-mini-window-height accordingly (what else could it do?) but if line-spacing is not nil, the bottom line(s) might not be visible. From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Aug 2021 18:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50178 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: 50178@debbugs.gnu.org Received: via spool by 50178-submit@debbugs.gnu.org id=B50178.162982880317981 (code B ref 50178); Tue, 24 Aug 2021 18:14:02 +0000 Received: (at 50178) by debbugs.gnu.org; 24 Aug 2021 18:13:23 +0000 Received: from localhost ([127.0.0.1]:45176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIavL-0004fv-B8 for submit@debbugs.gnu.org; Tue, 24 Aug 2021 14:13:23 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIavK-0004fg-3G for 50178@debbugs.gnu.org; Tue, 24 Aug 2021 14:13:22 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45862) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mIavE-0001dP-BJ; Tue, 24 Aug 2021 14:13:16 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2035 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 1mIavD-0001J2-QS; Tue, 24 Aug 2021 14:13:16 -0400 Date: Tue, 24 Aug 2021 21:13:08 +0300 Message-Id: <83y28qvhhn.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <875yvug2ka.fsf@telefonica.net> (message from =?UTF-8?Q?=C3=93scar?= Fuentes on Tue, 24 Aug 2021 19:44:37 +0200) References: <87eeajfvbq.fsf@telefonica.net> <83a6l7vyu2.fsf@gnu.org> <87a6l7ezks.fsf@telefonica.net> <837dgax1a0.fsf@gnu.org> <875yvug2ka.fsf@telefonica.net> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Óscar Fuentes > Cc: 50178@debbugs.gnu.org > Date: Tue, 24 Aug 2021 19:44:37 +0200 > X-Spam-Status: No > > > IOW, the value means "this many lines", but assuming that the line's > > height is the one you get with the frame's default font. > > IMAO the case where the user wants to ensure that the mini window is > capable of displaying at least X lines is much more common than the user > wanting a height of at least X times the default font's height. But the former is basically impossible to provide, not in Emacs 21+ with its support for variable-size fonts and display of images and xwidgets as part of text. Even with just different fonts, N lines using font of size X are not the same as N lines with size Y. > I suspect that max-mini-window-height was introduced with the former use > case in mind, but was not updated when line-spacing was implemented > later. No, max-mini-window-height is consistent with how we size all the windows in Emacs: in units of the canonical character height and width. That's our usual paradigm. > If we have no method for ensuring that the echo area is capable of > displaying at least X lines (within some reasonable limits) then we need > one. It would mean a different height for each piece of text you display. It will cause the mode line to jump up and down like a wild goat, even if a message applies some innocent non-default faces. It's not how Emacs is designed to work. It basically works in pixels, not in lines, and just converts from and to canonical character units to make it easier for users to specify values. > > You get the same in a window other than mini-window: if you set > > line-spacing, chances are the last screen line will be only partially > > visible. Why should the mini-window be different? it's just another > > window. > > You can't navigate around on the contents of the mini-window. ??? Of course, I can. What do you mean by "you can't"? The mini-window is just another window, so as long as you can make it the selected window (e.g., when the minibuffer is active), you can navigate there. > If a > package can't rely on setting max-mini-window-height for showing certain > number of lines on the mini-window, then it must implement vertical > scrolling, which makes things complex both on the programming side and > on the UI side, just to make sure that the user can access the content's > of the overflowing line(s), if any. The recipe you show in the bug report does support scrolling: the up- and down-arrow keys scroll the list of candidates. > The case of ido-grid-mode is glaring: it has a defcustom for setting how > many lines to show. When the command is invoked, it sets > max-mini-window-height accordingly (what else could it do?) but if > line-spacing is not nil, the bottom line(s) might not be visible. There was no ido-grid-mode in the original report, so I guess you are now talking about a different recipe? Can you present it? We could then discuss those problems and what can be done about that. From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Resent-From: =?UTF-8?Q?=C3=93scar?= Fuentes Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Aug 2021 18:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50178 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 50178@debbugs.gnu.org Received: via spool by 50178-submit@debbugs.gnu.org id=B50178.162983034420624 (code B ref 50178); Tue, 24 Aug 2021 18:40:01 +0000 Received: (at 50178) by debbugs.gnu.org; 24 Aug 2021 18:39:04 +0000 Received: from localhost ([127.0.0.1]:45218 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIbKB-0005Ma-Uq for submit@debbugs.gnu.org; Tue, 24 Aug 2021 14:39:04 -0400 Received: from relayout02-redir.e.movistar.es ([86.109.101.202]:31891) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIbKA-0005Lh-UF for 50178@debbugs.gnu.org; Tue, 24 Aug 2021 14:39:03 -0400 Received: from sky (14.red-79-145-70.dynamicip.rima-tde.net [79.145.70.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout02.e.movistar.es (Postfix) with ESMTPSA id 4GvHv501zQzdbJZ; Tue, 24 Aug 2021 20:38:56 +0200 (CEST) From: =?UTF-8?Q?=C3=93scar?= Fuentes 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> Date: Tue, 24 Aug 2021 20:38:56 +0200 In-Reply-To: <83y28qvhhn.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 24 Aug 2021 21:13:08 +0300") Message-ID: <871r6ig01r.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TnetOut-Country: IP: 79.145.70.14 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout02 X-TnetOut-MsgID: 4GvHv501zQzdbJZ.A8E09 X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1630435137.34578@Mp4AZAgdsZUaeY5YDDLdnA X-Spam-Status: No X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: >> IMAO the case where the user wants to ensure that the mini window is >> capable of displaying at least X lines is much more common than the user >> wanting a height of at least X times the default font's height. > > But the former is basically impossible to provide, not in Emacs 21+ > with its support for variable-size fonts and display of images and > xwidgets as part of text. Even with just different fonts, N lines > using font of size X are not the same as N lines with size Y. We are talking about the mini window here. It's contents are much more restricted, in the sense that it is determined by some command. This bug report is about such command wanting to show at least N lines, using the current display settings (font, line spacing, etc). >> You can't navigate around on the contents of the mini-window. > > ??? Of course, I can. What do you mean by "you can't"? The > mini-window is just another window, so as long as you can make it the > selected window (e.g., when the minibuffer is active), you can > navigate there. Allowing the user to move around on the mini window possibly is at odds with the UI of the command using the mini window. Certainly, it would be an inconvenience, as I mentioned before. >> If a >> package can't rely on setting max-mini-window-height for showing certain >> number of lines on the mini-window, then it must implement vertical >> scrolling, which makes things complex both on the programming side and >> on the UI side, just to make sure that the user can access the content's >> of the overflowing line(s), if any. > > The recipe you show in the bug report does support scrolling: the up- > and down-arrow keys scroll the list of candidates. Yes, that was just an example for demonstrating the problem using stock Emacs. Curiously, something like (message "foo1\nfoo2\nfoo3\nfoo4\nfoo4\nfoo5\nfoo6\nfoo7\nfoo8") doesn't show truncated lines because it apparently ignores the value of line-spacing. > There was no ido-grid-mode in the original report, so I guess you are > now talking about a different recipe? Can you present it? We could > then discuss those problems and what can be done about that. ido-grid-mode does not support vertical scrolling (it is not supposed to do that and it would be a burden if it did) and with certain values of line-spacing the last line(s) are partially visible or invisible. It's as simple as that. It uses max-mini-window-height for ensuring that the text fits on the mini-window, but that doesn't work on the presence of line-spacing. One workround would be to locally set line-spacing to nil (overriding the user's preferences), but this does not protect against other current or future settings that might affect how the lines are rendered. From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Aug 2021 18:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50178 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: 50178@debbugs.gnu.org Received: via spool by 50178-submit@debbugs.gnu.org id=B50178.162983096221645 (code B ref 50178); Tue, 24 Aug 2021 18:50:02 +0000 Received: (at 50178) by debbugs.gnu.org; 24 Aug 2021 18:49:22 +0000 Received: from localhost ([127.0.0.1]:45232 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIbUA-0005d2-Dq for submit@debbugs.gnu.org; Tue, 24 Aug 2021 14:49:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34474) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIbU7-0005cm-V7 for 50178@debbugs.gnu.org; Tue, 24 Aug 2021 14:49:20 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46300) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mIbU2-0000rO-4C; Tue, 24 Aug 2021 14:49:14 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4261 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 1mIbU1-0006Ky-MP; Tue, 24 Aug 2021 14:49:14 -0400 Date: Tue, 24 Aug 2021 21:49:08 +0300 Message-Id: <83wnoavftn.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <871r6ig01r.fsf@telefonica.net> (message from =?UTF-8?Q?=C3=93scar?= Fuentes on Tue, 24 Aug 2021 20:38:56 +0200) 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> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Óscar Fuentes > Cc: 50178@debbugs.gnu.org > Date: Tue, 24 Aug 2021 20:38:56 +0200 > > Eli Zaretskii writes: > > > But the former is basically impossible to provide, not in Emacs 21+ > > with its support for variable-size fonts and display of images and > > xwidgets as part of text. Even with just different fonts, N lines > > using font of size X are not the same as N lines with size Y. > > We are talking about the mini window here. It's contents are much more > restricted, in the sense that it is determined by some command. I don't really see how can we say that, given the proliferation of the various completion packages, which display everything that can be displayed in the mini-window. > This bug report is about such command wanting to show at least N > lines, using the current display settings (font, line spacing, etc). And I still don't understand what is wrong with the recipe you've shown. In my testing, I see a very long list of candidates, with several ones fully visible and one visible only partially. I can scroll down the list to see more candidates, including the one which was initially displayed partially. I fail to see a problem with that, sorry. > >> You can't navigate around on the contents of the mini-window. > > > > ??? Of course, I can. What do you mean by "you can't"? The > > mini-window is just another window, so as long as you can make it the > > selected window (e.g., when the minibuffer is active), you can > > navigate there. > > Allowing the user to move around on the mini window possibly is at odds > with the UI of the command using the mini window. Certainly, it would be > an inconvenience, as I mentioned before. Again, I don't see any inconvenience. It's just the normal vertical motion of the cursor, not unlike any other window. > Curiously, something like > > (message "foo1\nfoo2\nfoo3\nfoo4\nfoo4\nfoo5\nfoo6\nfoo7\nfoo8") > > doesn't show truncated lines because it apparently ignores the value of > line-spacing. It does here, I guess you didn't turn line-spacing by default or something. Try emacs -Q --eval "(setq-default line-spacing 0.2)" > ido-grid-mode does not support vertical scrolling (it is not supposed to > do that and it would be a burden if it did) and with certain values of > line-spacing the last line(s) are partially visible or invisible. It's > as simple as that. It uses max-mini-window-height for ensuring that the > text fits on the mini-window, but that doesn't work on the presence of > line-spacing. > > One workround would be to locally set line-spacing to nil (overriding > the user's preferences), but this does not protect against other current > or future settings that might affect how the lines are rendered. Or it could calculate max-mini-window-height more accurately. From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Resent-From: =?UTF-8?Q?=C3=93scar?= Fuentes Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Aug 2021 19:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50178 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 50178@debbugs.gnu.org Received: via spool by 50178-submit@debbugs.gnu.org id=B50178.162983383526747 (code B ref 50178); Tue, 24 Aug 2021 19:38:01 +0000 Received: (at 50178) by debbugs.gnu.org; 24 Aug 2021 19:37:15 +0000 Received: from localhost ([127.0.0.1]:45278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIcER-0006xE-Fc for submit@debbugs.gnu.org; Tue, 24 Aug 2021 15:37:15 -0400 Received: from relayout02-redir.e.movistar.es ([86.109.101.202]:61809) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIcEL-0006wZ-Mg for 50178@debbugs.gnu.org; Tue, 24 Aug 2021 15:37:09 -0400 Received: from sky (14.red-79-145-70.dynamicip.rima-tde.net [79.145.70.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout02.e.movistar.es (Postfix) with ESMTPSA id 4GvKB34LXxzdbjb; Tue, 24 Aug 2021 21:36:59 +0200 (CEST) From: =?UTF-8?Q?=C3=93scar?= Fuentes 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> Date: Tue, 24 Aug 2021 21:36:58 +0200 In-Reply-To: <83wnoavftn.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 24 Aug 2021 21:49:08 +0300") Message-ID: <87wnoaeisl.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TnetOut-Country: IP: 79.145.70.14 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout02 X-TnetOut-MsgID: 4GvKB34LXxzdbjb.A9E82 X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1630438619.99149@9KrYzrEzBUrOYoZtjJn8KQ X-Spam-Status: No X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: >> One workround would be to locally set line-spacing to nil (overriding >> the user's preferences), but this does not protect against other current >> or future settings that might affect how the lines are rendered. > > Or it could calculate max-mini-window-height more accurately. It must know and handle every setting that affects line height, current and future. It would be handy if Emacs provided a function that does that. From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Aug 2021 02:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50178 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: 50178@debbugs.gnu.org Received: via spool by 50178-submit@debbugs.gnu.org id=B50178.162985833015606 (code B ref 50178); Wed, 25 Aug 2021 02:26:02 +0000 Received: (at 50178) by debbugs.gnu.org; 25 Aug 2021 02:25:30 +0000 Received: from localhost ([127.0.0.1]:45395 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIiba-00043e-CY for submit@debbugs.gnu.org; Tue, 24 Aug 2021 22:25:30 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52234) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIibY-00043Q-Iq for 50178@debbugs.gnu.org; Tue, 24 Aug 2021 22:25:29 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60832) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mIibS-0003ts-Eu; Tue, 24 Aug 2021 22:25:22 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4208 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 1mIibK-0005aA-FT; Tue, 24 Aug 2021 22:25:22 -0400 Date: Wed, 25 Aug 2021 05:24:58 +0300 Message-Id: <83sfyyuupx.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87wnoaeisl.fsf@telefonica.net> (message from =?UTF-8?Q?=C3=93scar?= Fuentes on Tue, 24 Aug 2021 21:36:58 +0200) 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> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Óscar Fuentes > Cc: 50178@debbugs.gnu.org > Date: Tue, 24 Aug 2021 21:36:58 +0200 > > Eli Zaretskii writes: > > > Or it could calculate max-mini-window-height more accurately. > > It must know and handle every setting that affects line height, current > and future. It would be handy if Emacs provided a function that does > that. We already have it: window-text-pixel-size. From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Aug 2021 07:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50178 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , =?UTF-8?Q?=C3=93scar?= Fuentes Cc: 50178@debbugs.gnu.org Received: via spool by 50178-submit@debbugs.gnu.org id=B50178.162987776014616 (code B ref 50178); Wed, 25 Aug 2021 07:50:02 +0000 Received: (at 50178) by debbugs.gnu.org; 25 Aug 2021 07:49:20 +0000 Received: from localhost ([127.0.0.1]:45621 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIney-0003ng-6b for submit@debbugs.gnu.org; Wed, 25 Aug 2021 03:49:20 -0400 Received: from mout.gmx.net ([212.227.15.15]:45845) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mInew-0003nT-RG for 50178@debbugs.gnu.org; Wed, 25 Aug 2021 03:49:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1629877752; bh=wdeNPCcobJhAejPeJ67XbV5TInatUuM4LdY6FkXFweA=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=aK5QpImeYQWcwe1WhiXjI1bwx8+JjmyxEUJBf587VMvi1UKY5BGpINtbNbE7BRPiJ kFI4W0Q3JIRXF7ihbfZcSiPjfKdWpwOPsNQI5by5xPWgECKUFnYn6ZJRYileC1zfLw hzOvHwSaeL/S02gRXKi7+iR04NSag92J2/TCU0pw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.102] ([212.95.5.185]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M1poA-1mL0aF3vPk-002F13; Wed, 25 Aug 2021 09:49:12 +0200 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> From: martin rudalics Message-ID: Date: Wed, 25 Aug 2021 09:49:11 +0200 MIME-Version: 1.0 In-Reply-To: <83sfyyuupx.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:avxXODWhBovGrYIHb/5Wi4yS8kBXn4C4xCsJ1g68jZrfy+m16Aa CGYZKSC1bm+LltvtPyVpXgL5me/ubb6olr9/LPYVXt/9TkrsBSXMZSZ0+ieIcqwPZWuyynM jFIgq0SnFKFCqGbDKobDynPybvdryu9G5CTNkpZPvwXyAD/x6pHNpukzCRs1aqiGgBwsVUe coGlqfP/knAxkRpXqjMCQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:d+hUU/9yptk=:fqaZ/9oO0sV20j2xcUR0Mo wryxzUvW8LM/NsVmh4+UCUcPlkQapT+6LIv9PThRLB1kA3FCAahSKj9gf7EGdszhnyXRakJMb RqPYDelKMdBxQG4jVwKbz49jZx6qVIzVkUBgaEGIOrLt55vJ1eGIUN3uKXOcUgXy3yhHMkf9y wCxsoUR7tn97JU2VCJ3FXivbAD77HawdbQTGywpi83rr4YsIOlo9azBUH5iuKJm4hTQ5qRV0d XZ2NMZuXw0c7JkBLz8VnfrQGy2nr8ltM9ft7EzgbZBa40ibcgCrVFNvYf0HTj7mCzmlIcE2KJ Xet/fcds0s2Dl1zCZVAeWCxrXLmtiwtLz4GUg7dBaZYZq4AFgqa4baKn9ItPX4lFv/vIszzz6 wXWougeNolNInSkWbdRQpvs4PxFWT+1WfDBgb5zJshbByxr0y9JfeJGl0d/bBV0/+oAqkKhzW LkMAumpy7NA/gtB3C1B7Dmhf37sxrnG0bSBPpilbnAkIO9q0ewBcGXrkWFkPe6c2ma31fZd7d jwfkdmsDl7v3/ZROQg3sPOKD9ryrUY0qFnkFNSGHslt+AKsKE6jyHcHeD+Z+ttTEgXWfvnJ1c JdQbebD7eapALnQeSjPdt+qXIxyih1QxgLoTANOEe+S40NcFwbVo4nZdfTLMqG+m/UloYwP/7 A2HlT0ETs03tYk9XE7r6Aj0S0ZwhcSCGnG+O9lDn2nnrWfs6a1syHW7zNfuGd1jS35IvDhUIR vEA36DC6iE33vX1s4N69rdHGj4/IQnK/ScFa4tSf0hKuRm6tlyA8kMdEkPufAKLcGTA4zc4VM T6FDTroj2JGiN5AFz0uVDQ5eU11N2ok4vuvUAb5oEGA/F6FkCQWEnlwKr+t6E93omHKQl8NXS lufTuKur1xal7DOX3DYPUORh2n3pwoPM/W8OX+WkgGOQeIRoK0fmkUe2UrxRYcRPR5g75iopV oCmDBB6dGI/uoQHBPAhVDvVfuKVM/JNyku25Byc0vB75R/L/PUx1PO9UGyPjT4vfWDJZv6PU9 w716gWraeK5rX7cou0cuQz9IwQSLplOuJEXUb4zMSIDxZDQlDu2fvcRBFKox+JGA7iBMY/LU3 6pcqE+czMWyan8TQDlX/smYvlopQ29ZiGcdBERZ3ELmqQjXEzVdAXuRFg== X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> It must know and handle every setting that affects line height, current >> and future. It would be handy if Emacs provided a function that does >> that. > > We already have it: window-text-pixel-size. To elaborate: (1) You first have to calculate the maximum permissible pixel height of the echo area window from the character height of the frame where you intend to display the completions and the value of `max-mini-window-height' height as specified for that frame. Note that for a minibuffer-less frame the echo area window may appear on another frame whose character height you have to use here. (2) You then have to calculate the pixel height of each completion line as if it were shown in the echo area window mentioned in (1) using `window-text-pixel-size' and add it to some cumulative height until you have exhausted the maximum permissible height calculated in (1). martin From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Aug 2021 09:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50178 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: =?UTF-8?Q?=C3=93scar?= Fuentes , Eli Zaretskii , 50178@debbugs.gnu.org Received: via spool by 50178-submit@debbugs.gnu.org id=B50178.162988208421554 (code B ref 50178); Wed, 25 Aug 2021 09:02:02 +0000 Received: (at 50178) by debbugs.gnu.org; 25 Aug 2021 09:01:24 +0000 Received: from localhost ([127.0.0.1]:45699 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIomi-0005ba-1x for submit@debbugs.gnu.org; Wed, 25 Aug 2021 05:01:24 -0400 Received: from heytings.org ([95.142.160.155]:32786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIomf-0005bS-Sa for 50178@debbugs.gnu.org; Wed, 25 Aug 2021 05:01:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1629882081; bh=H5Av06yBOPzjO+XoEGHMqhBjD1j/k+7fSkv0Qml3MWI=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=xU4ZL71yJUQi6qTrFHPsqMtCWCUsL4SRyKTFR1aOAgKeAmzbVL88cPFZcoaR6Yn9C ATHvxRzHrfemOLpgqKEoP+zsMvDFknd0dpXI5oRfjR1tPX/KLX5ZOC8vO1mRrDrp7x nS90K4dBtczJji6ATJpqRu3o4ssy+bcIawWTcN+X8ihetYQ3TeMwgD+F2uCAZsT0Xn hb4NDyooMyK3YxUVtp3PGq+lojmzg+Pz97eRLLja5gyUC+Kh4SbCl9XGoAVaELKtq8 q5yulPkF2u+2X5XN4eToWet2LRbup2i6iUqHFa8Y6BbNRX8db4nuVMPt4jmgf6JVWa DX8KPlGSGkdvg== Date: Wed, 25 Aug 2021 09:01:20 +0000 From: Gregory Heytings In-Reply-To: Message-ID: 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> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > To elaborate: > > (1) You first have to calculate the maximum permissible pixel height of > the echo area window from the character height of the frame where you > intend to display the completions and the value of > `max-mini-window-height' height as specified for that frame. Note that > for a minibuffer-less frame the echo area window may appear on another > frame whose character height you have to use here. > > (2) You then have to calculate the pixel height of each completion line > as if it were shown in the echo area window mentioned in (1) using > `window-text-pixel-size' and add it to some cumulative height until you > have exhausted the maximum permissible height calculated in (1). > If you can live with the fact that the last visible completion candidate is not fully displayed (which is, as Eli said, consistent with what happens in other Emacs windows), this complex procedure is not necessary anymore. You can simply set redisplay-adhoc-scroll-in-resize-mini-windows to nil and insert "enough" completion candidates. Emacs will resize the window appropriately, and the last completion candidates will not be visible. From unknown Sun Jun 22 07:48:00 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: =?UTF-8?Q?=C3=93scar?= Fuentes Subject: bug#50178: closed (Re: bug#50178: 28.0.50; Size of echo area does not account for line-spacing) Message-ID: References: <87k0k9er3w.fsf@telefonica.net> <87eeajfvbq.fsf@telefonica.net> X-Gnu-PR-Message: they-closed 50178 X-Gnu-PR-Package: emacs Reply-To: 50178@debbugs.gnu.org Date: Wed, 25 Aug 2021 10:50:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1629888602-13824-1" This is a multi-part message in MIME format... ------------=_1629888602-13824-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #50178: 28.0.50; Size of echo area does not account for line-spacing which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 50178@debbugs.gnu.org. --=20 50178: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D50178 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1629888602-13824-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 50178-done) by debbugs.gnu.org; 25 Aug 2021 10:49:52 +0000 Received: from localhost ([127.0.0.1]:45863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIqTf-0003aW-MJ for submit@debbugs.gnu.org; Wed, 25 Aug 2021 06:49:51 -0400 Received: from relayout02.e.movistar.es ([86.109.101.202]:38273 helo=relayout02-redir.e.movistar.es) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIqTa-0003aF-JB for 50178-done@debbugs.gnu.org; Wed, 25 Aug 2021 06:49:50 -0400 Received: from sky (14.red-79-145-70.dynamicip.rima-tde.net [79.145.70.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout02.e.movistar.es (Postfix) with ESMTPSA id 4GvjR820KYzdcRw; Wed, 25 Aug 2021 12:49:39 +0200 (CEST) From: =?utf-8?Q?=C3=93scar_Fuentes?= To: martin rudalics Subject: Re: bug#50178: 28.0.50; Size of echo area does not account for line-spacing 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> Date: Wed, 25 Aug 2021 12:49:39 +0200 In-Reply-To: (martin rudalics's message of "Wed, 25 Aug 2021 09:49:11 +0200") Message-ID: <87k0k9er3w.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TnetOut-Country: IP: 79.145.70.14 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout02 X-TnetOut-MsgID: 4GvjR820KYzdcRw.AB220 X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1630493380.73406@36Oaf6Ru+srfVN7lYi6CGw X-Spam-Status: No X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 50178-done Cc: Eli Zaretskii , 50178-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) martin rudalics writes: >>> It must know and handle every setting that affects line height, current >>> and future. It would be handy if Emacs provided a function that does >>> that. >> >> We already have it: window-text-pixel-size. > > To elaborate: > > (1) You first have to calculate the maximum permissible pixel height of > the echo area window from the character height of the frame where > you intend to display the completions and the value of > `max-mini-window-height' height as specified for that frame. Note > that for a minibuffer-less frame the echo area window may appear on > another frame whose character height you have to use here. > > (2) You then have to calculate the pixel height of each completion line > as if it were shown in the echo area window mentioned in (1) using > `window-text-pixel-size' and add it to some cumulative height until > you have exhausted the maximum permissible height calculated in (1). Thanks. That's too complicated and looks like there are quite a bit of hidden traps, so for the time being I'll set line-spacing to nil. On true pixel-oriented systems there are APIs for querying the display engine about several metrics. Then you can place the text at certain pixel coordinates. Emacs, however, is a Frankenstein system, that uses pixels (on graphic frames) but the text positioning depends on previous text, i.e. for vertical positioning it is a line-based, not pixel-based, system. Therefore, when you just need to output some lines, you must deal with pixels, translate back to lines and, to add insult to injury, resort to post-facto information. As useful as it would be an API that returns how many lines fit on a given window. Or, on this case, max-mini-window-height being a true indication of the capacity of the mini window on terms of the current display settings, which is what the users want 99.9% of the time. Closing. ------------=_1629888602-13824-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 24 Aug 2021 02:08:59 +0000 Received: from localhost ([127.0.0.1]:42852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mILrz-00083W-D0 for submit@debbugs.gnu.org; Mon, 23 Aug 2021 22:08:59 -0400 Received: from lists.gnu.org ([209.51.188.17]:41704) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mILru-00083M-Sr for submit@debbugs.gnu.org; Mon, 23 Aug 2021 22:08:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42368) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mILru-0000Bz-C4 for bug-gnu-emacs@gnu.org; Mon, 23 Aug 2021 22:08:50 -0400 Received: from relayout03.e.movistar.es ([86.109.101.203]:36995 helo=relayout03-redir.e.movistar.es) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mILrr-0008M4-NZ for bug-gnu-emacs@gnu.org; Mon, 23 Aug 2021 22:08:49 -0400 Received: from sky (14.red-79-145-70.dynamicip.rima-tde.net [79.145.70.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout03.e.movistar.es (Postfix) with ESMTPSA id 4GtswT4xYQzMksW for ; Tue, 24 Aug 2021 04:08:41 +0200 (CEST) From: =?utf-8?Q?=C3=93scar_Fuentes?= To: bug-gnu-emacs@gnu.org Subject: 28.0.50; Size of echo area does not account for line-spacing Date: Tue, 24 Aug 2021 04:08:41 +0200 Message-ID: <87eeajfvbq.fsf@telefonica.net> MIME-Version: 1.0 Content-Type: text/plain X-TnetOut-Country: IP: 79.145.70.14 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout03 X-TnetOut-MsgID: 4GtswT4xYQzMksW.A068A X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1630375722.51984@VfOD/ML5UnJHathhgt9Wvw X-Spam-Status: No Received-SPF: softfail client-ip=86.109.101.203; envelope-from=ofv@wanadoo.es; helo=relayout03-redir.e.movistar.es X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Seems that on some circunstances the vertical space calculated for the text on the echo area does not account for the value of line-spacing: emacs -Q M-x icomplete-vertical-mode M-x fido-mode (set-default 'line-spacing 0.1) Now M-x will display a list of candidates with the last candidate partially visible for lack of vertical space. In GNU Emacs 28.0.50 (build 4, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0) of 2021-07-30 built on sky Repository revision: d9bc7dbefd88995d04b9843f521d82118265fecf Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: Debian GNU/Linux 11 (bullseye) Configured using: 'configure --with-native-compilation --without-toolkit-scroll-bars --with-x-toolkit=lucid --with-modules --without-imagemagick build_alias= host_alias= target_alias=' Configured features: CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBOTF LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF X11 XAW3D XDBE XIM XPM LUCID ZLIB ------------=_1629888602-13824-1-- From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Aug 2021 12:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50178 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: rudalics@gmx.at, 50178@debbugs.gnu.org Received: via spool by 50178-submit@debbugs.gnu.org id=B50178.162989376030787 (code B ref 50178); Wed, 25 Aug 2021 12:16:02 +0000 Received: (at 50178) by debbugs.gnu.org; 25 Aug 2021 12:16:00 +0000 Received: from localhost ([127.0.0.1]:45999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIrp2-00080V-B1 for submit@debbugs.gnu.org; Wed, 25 Aug 2021 08:16:00 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53364) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIroz-00080I-Vx for 50178@debbugs.gnu.org; Wed, 25 Aug 2021 08:15:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44854) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mIrot-0007QG-SI; Wed, 25 Aug 2021 08:15:51 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4360 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 1mIroq-0001dh-6b; Wed, 25 Aug 2021 08:15:51 -0400 Date: Wed, 25 Aug 2021 15:15:44 +0300 Message-Id: <83ilztvhxr.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87k0k9er3w.fsf@telefonica.net> (message from =?UTF-8?Q?=C3=93scar?= Fuentes on Wed, 25 Aug 2021 12:49:39 +0200) 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> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Óscar Fuentes > Cc: Eli Zaretskii , 50178-done@debbugs.gnu.org > Date: Wed, 25 Aug 2021 12:49:39 +0200 > > As useful as it would be an API that returns how many lines fit on a > given window. What is a "line" for this purpose? The notion of a "canonical line" is well defined, and that is what we use. Any other notion will have to be defined first, and it isn't easy, I can tell you. > Or, on this case, max-mini-window-height being a true > indication of the capacity of the mini window on terms of the current > display settings, which is what the users want 99.9% of the time. Unless you counted only yourself in those 99.9%, it is a strange thing to say about the modern Emacs. It's as if you wanted to go back to Emacs 18, where all lines were the same height. From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Aug 2021 14:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50178 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: martin rudalics , 50178-done@debbugs.gnu.org Received: via spool by 50178-done@debbugs.gnu.org id=D50178.162990202221727 (code D ref 50178); Wed, 25 Aug 2021 14:34:01 +0000 Received: (at 50178-done) by debbugs.gnu.org; 25 Aug 2021 14:33:42 +0000 Received: from localhost ([127.0.0.1]:47277 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mItyH-0005eN-NB for submit@debbugs.gnu.org; Wed, 25 Aug 2021 10:33:41 -0400 Received: from heytings.org ([95.142.160.155]:33190) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mItyC-0005eB-Ri for 50178-done@debbugs.gnu.org; Wed, 25 Aug 2021 10:33:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1629902015; bh=bOClD2h3omwjjdIiUAsnldkVe3hjfrvTg5bnImvSLtY=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=oS64rls4zSFbj53q9DQpVXSocdBcBcpsjthZNkWFg7ChJK1YAwExqRibf1Y6YbXB1 UqvNTzUyJqLMN/mvWap+xJSWRDkfU43nZe31tSAnpwLVdLfHIbo4/Av4LdT78odCEg q1jwCVe/hfxtIYC8A1IdpDJYb1tq9Kt0MFlTvP//gC7XWAUtqN1w9CeUTEZvsepdAF 4ciIX5C93rE/kteb/cjFC6u2lyO6u7WVJww8apNBo0R7qmEJ4Ww8wPYeb6g6621hLk CZBz2g85gpETvIbhK8EQ5eOeBe36GgzRXketvGCoMyIkH9UX7n7x5QGgF/40HXR5Q1 /+9R8GQAN7giw== Date: Wed, 25 Aug 2021 14:33:35 +0000 From: Gregory Heytings In-Reply-To: <87k0k9er3w.fsf@telefonica.net> Message-ID: 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> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > On true pixel-oriented systems there are APIs for querying the display > engine about several metrics. Then you can place the text at certain > pixel coordinates. Emacs, however, is a Frankenstein system, that uses > pixels (on graphic frames) but the text positioning depends on previous > text, i.e. for vertical positioning it is a line-based, not pixel-based, > system. Therefore, when you just need to output some lines, you must > deal with pixels, translate back to lines and, to add insult to injury, > resort to post-facto information. > > As useful as it would be an API that returns how many lines fit on a > given window. Or, on this case, max-mini-window-height being a true > indication of the capacity of the mini window on terms of the current > display settings, which is what the users want 99.9% of the time. > Try emacs -Q, C-h h to see why it is impossible to have "an API that returns how many lines fit on a given window". From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Resent-From: =?UTF-8?Q?=C3=93scar?= Fuentes Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Aug 2021 17:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50178 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gregory Heytings Cc: martin rudalics , 50178-done@debbugs.gnu.org Received: via spool by 50178-done@debbugs.gnu.org id=D50178.16299113655192 (code D ref 50178); Wed, 25 Aug 2021 17:10:01 +0000 Received: (at 50178-done) by debbugs.gnu.org; 25 Aug 2021 17:09:25 +0000 Received: from localhost ([127.0.0.1]:47536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIwOz-0001Lg-DT for submit@debbugs.gnu.org; Wed, 25 Aug 2021 13:09:25 -0400 Received: from relayout02.e.movistar.es ([86.109.101.202]:54717 helo=relayout02-redir.e.movistar.es) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIwOw-0001LP-Bf for 50178-done@debbugs.gnu.org; Wed, 25 Aug 2021 13:09:23 -0400 Received: from sky (14.red-79-145-70.dynamicip.rima-tde.net [79.145.70.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout02.e.movistar.es (Postfix) with ESMTPSA id 4Gvss65LC8zdcYY; Wed, 25 Aug 2021 19:09:14 +0200 (CEST) From: =?UTF-8?Q?=C3=93scar?= Fuentes 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> Date: Wed, 25 Aug 2021 19:09:14 +0200 In-Reply-To: (Gregory Heytings's message of "Wed, 25 Aug 2021 14:33:35 +0000") Message-ID: <87fsuxe9j9.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-TnetOut-Country: IP: 79.145.70.14 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout02 X-TnetOut-MsgID: 4Gvss65LC8zdcYY.A95DA X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1630516155.13836@Vd1nGEFZWQDTUA2p2R5bXQ X-Spam-Status: No X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Gregory Heytings writes: > Try emacs -Q, C-h h to see why it is impossible to have "an API that > returns how many lines fit on a given window". Any graphics environment worth its salt has methods for measuring whatever object without actually rendering it. It's also true that those systems work on pixels (or some other suitable, fine-grained unit) all the way, they do not reveal themselves as TTY-oriented systems when the user says "ok, then put this right here." The impossibility you mention is a limitation of Emacs. So going back to Emacs, the doctstring of max-mini-window-height is "... If an integer, it specifies the maximum height in units of the mini-window frame=E2=80=99s default font=E2=80=99s height. " Why that was implemented that way? (instead of using pixels, for instance.) Maybe because the relevant use case was to support resizing the mini window on a way that guarantees that certain number of lines (rendered on the default font) will fit on it? From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Aug 2021 17:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50178 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: gregory@heytings.org, 50178@debbugs.gnu.org Received: via spool by 50178-submit@debbugs.gnu.org id=B50178.16299142389556 (code B ref 50178); Wed, 25 Aug 2021 17:58:01 +0000 Received: (at 50178) by debbugs.gnu.org; 25 Aug 2021 17:57:18 +0000 Received: from localhost ([127.0.0.1]:47570 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIx9J-0002U4-M9 for submit@debbugs.gnu.org; Wed, 25 Aug 2021 13:57:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40812) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIx9G-0002To-3M for 50178@debbugs.gnu.org; Wed, 25 Aug 2021 13:57:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55058) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mIx99-00059Z-RB; Wed, 25 Aug 2021 13:57:07 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1805 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 1mIx99-0000PI-Dm; Wed, 25 Aug 2021 13:57:07 -0400 Date: Wed, 25 Aug 2021 20:57:02 +0300 Message-Id: <83zgt5tnkh.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87fsuxe9j9.fsf@telefonica.net> (message from =?UTF-8?Q?=C3=93scar?= Fuentes on Wed, 25 Aug 2021 19:09:14 +0200) 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> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Óscar Fuentes > Date: Wed, 25 Aug 2021 19:09:14 +0200 > Cc: 50178-done@debbugs.gnu.org > > Gregory Heytings writes: > > > Try emacs -Q, C-h h to see why it is impossible to have "an API that > > returns how many lines fit on a given window". > > 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. > If an integer, it specifies the maximum height in units of the > mini-window frame’s default font’s height. > " > > 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. From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Resent-From: =?UTF-8?Q?=C3=93scar?= Fuentes Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Aug 2021 20:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50178 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: gregory@heytings.org, 50178@debbugs.gnu.org Received: via spool by 50178-submit@debbugs.gnu.org id=B50178.162992221531546 (code B ref 50178); Wed, 25 Aug 2021 20:11:01 +0000 Received: (at 50178) by debbugs.gnu.org; 25 Aug 2021 20:10:15 +0000 Received: from localhost ([127.0.0.1]:47941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIzDz-0008Cj-47 for submit@debbugs.gnu.org; Wed, 25 Aug 2021 16:10:15 -0400 Received: from relayout01.e.movistar.es ([86.109.101.201]:24613 helo=relayout01-redir.e.movistar.es) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIzDw-0008CL-By for 50178@debbugs.gnu.org; Wed, 25 Aug 2021 16:10:13 -0400 Received: from sky (14.red-79-145-70.dynamicip.rima-tde.net [79.145.70.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout01.e.movistar.es (Postfix) with ESMTPSA id 4Gvxsm1wqWzfZC1; Wed, 25 Aug 2021 22:10:03 +0200 (CEST) From: =?UTF-8?Q?=C3=93scar?= Fuentes 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> Date: Wed, 25 Aug 2021 22:10:03 +0200 In-Reply-To: <83zgt5tnkh.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 25 Aug 2021 20:57:02 +0300") Message-ID: <878s0pe15w.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-TnetOut-Country: IP: 79.145.70.14 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout01 X-TnetOut-MsgID: 4Gvxsm1wqWzfZC1.A073E X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1630527005.459@IMVPA7uylyEwcC2okpkK6A X-Spam-Status: No X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 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". 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) 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. >> If an integer, it specifies the maximum height in units of the >> mini-window frame=E2=80=99s default font=E2=80=99s height. >> " >>=20 >> 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. From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing 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 X-GNU-PR-Keywords: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: gregory@heytings.org, 50178@debbugs.gnu.org Received: via spool by 50178-submit@debbugs.gnu.org id=B50178.16299596961133 (code B ref 50178); Thu, 26 Aug 2021 06:35:02 +0000 Received: (at 50178) by debbugs.gnu.org; 26 Aug 2021 06:34:56 +0000 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 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 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 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 Date: Thu, 26 Aug 2021 09:34:29 +0300 Message-Id: <83sfywu32i.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <878s0pe15w.fsf@telefonica.net> (message from =?UTF-8?Q?=C3=93scar?= Fuentes on Wed, 25 Aug 2021 22:10:03 +0200) 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 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Aug 2021 07:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50178 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: Eli Zaretskii , 50178-done@debbugs.gnu.org Received: via spool by 50178-done@debbugs.gnu.org id=D50178.162996450217329 (code D ref 50178); Thu, 26 Aug 2021 07:56:02 +0000 Received: (at 50178-done) by debbugs.gnu.org; 26 Aug 2021 07:55:02 +0000 Received: from localhost ([127.0.0.1]:48309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mJAE2-0004VG-2t for submit@debbugs.gnu.org; Thu, 26 Aug 2021 03:55:02 -0400 Received: from mout.gmx.net ([212.227.17.21]:36769) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mJADz-0004Ur-5v for 50178-done@debbugs.gnu.org; Thu, 26 Aug 2021 03:55:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1629964492; bh=RRhlboEU2QajpCJFmDIonLi1/6s4dfJcBt57ulBHREQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=kls+YLVR7F216fd7S4yO3yb9COr5GZBne2l5v51MA3PWmRXTywvFUWxREtFiGyVEe jbZ6EJlJdblnWE17IiTzoLMvpp702Jf1HWX+Z7jpHGKZWmWxlfetlpBB/es4smb4Ut nBVqR/AaVXsfnzfk+FALX26nl22McRmkRjEbEPzU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.102] ([212.95.5.85]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M5fMY-1mPDxx35o2-0079oO; Thu, 26 Aug 2021 09:54:51 +0200 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> From: martin rudalics Message-ID: <2acd8c0f-443e-3521-20a4-05369193b899@gmx.at> Date: Thu, 26 Aug 2021 09:54:51 +0200 MIME-Version: 1.0 In-Reply-To: <87k0k9er3w.fsf@telefonica.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:jwaf/7XidTDCgP+lfO+fp23q6suRXGvs4n8o4RSHBxgcljQ3Y4X iYG1vXzTahLLJOQjxUMA0YBZJP2Hcs3NPc8JP5AR85TTUYqNAfvg5eYFa+zH7elet7g+Fuf nG970lnbzlaUhdI5mU893aagaaDFOlm2qbYL+LNqaV9K/KLrU14Q4mupDysgi1ZT1pPR70K btPevY5d2dudRKuaz1x+w== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:D2BdlSZfeZ4=:1QOVutZWz6XXEMyNrvWBKi Y9yfzy9z8r2HMTUlftN5XjUpiV5t4VhwgLYR+tpMjJ0lcF9edqV5idW9nHxLFj9rfED25NAA5 KEemKdEWIcYW4SwrzQDNNIPxsMz3UQlZ9Q/31yBAs+/Nc9Mafcx9rGMs2BAaxHe+7lqpYCHl8 n5/JxFLxbQpSDxnoYIO/qASBO9/D0EQDRY/+u2fkjQfBB/tZmLK7fFqgErCoXj0OhZUv1/PHL yCM5Tb918xnD43vovvfTSMkmWb3SHpHDBL9v+rGdU4TSncjJIc4vQTTKOLDAhTg1nBVySUa5t OI3ARdAvkw+OM0absqZzBx9eJFGu2K7Bj7/53rrHo7d9RJ70ZENWmDdzMfhaIQdF33zfwsibN UCfggyebYbkmsHu4c5BEwSK1zzqjJ7JBoenYY+1gDrGxQFRx2JBObLCwI1F7LavouyH+8eu+o tU5Tsi4uGRGgCGFN6DPkA8ptzFSGo9/BRs4jZGHFtd49YZtzHUTKOvz00S8YnOkRMMBSQCe1L nGDgIwtaTa5qbRjpkhUsRB/odGhVwftfEH12hgPpW82rbABMgcybUeK8mxrVrjZcm6KPBrhC8 8IdbiBOltGtXyndOEQIyn2OEd7zVAmJ7Z0k4bIZy/X6LE/dI838DGoU/U+dDxaE5iti9oXeVJ EAI7IGI5c7ClTLqPzTHUznrSGknIw8lFftL+6wYVClCxmtkuuWz6UghAKaY0dt4IUcHs+C5y8 DmDDrhoU4gMGq8owUxU5Zqra6mrEKFRKUgAyOcXzD6U8V1LjO36gz39QAkb/AW8E5gI3RbyYS GbQJXFJ7zNDcFsBPpMajrkY7ppujh2n6CPxaBDdmv84HGh4/b7PWtfnEQ463t1dXg+HwlbIC7 WJRNUwE7inwLeGepeADb4TnDKseSoeMNn5lvxcxSnXgitMG8RaPzN21aOZWBYCVKJp2zKQMf0 BZTZcwvtsEPx2AfvS4TJS2hMx3Oykc7O6OeVI6xAUtgTSZVYorAw4QPlB1DVrgnG0BO5t2klk 5NUXlgvAoZwGLmjUiA9JiHOjr/c/p4HWubVU2UgklXDPAiNqPfAlPybZprRcrDvj9YSXJUSZK BwRJ2h7XeMegnmNXMOeCeA4AlCBKlJuaNaKt/dMreq5j64Fm9dqCuaW9Q== X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On true pixel-oriented systems there are APIs for querying the display > engine about several metrics. Then you can place the text at certain > pixel coordinates. Emacs, however, is a Frankenstein system, that uses > pixels (on graphic frames) but the text positioning depends on previous > text, i.e. for vertical positioning it is a line-based, not pixel-based, > system. Therefore, when you just need to output some lines, you must > deal with pixels, translate back to lines and, to add insult to injury, > resort to post-facto information. Users think in terms of lines and columns. True pixel-oriented systems are not convenient for editing. A few days ago I spent a couple of hours to remove one single line from a pdf-document using LibreOffice. I almost succeeded. > As useful as it would be an API that returns how many lines fit on a > given window. Or, on this case, max-mini-window-height being a true > indication of the capacity of the mini window on terms of the current > display settings, which is what the users want 99.9% of the time. Did you try with `redisplay-adhoc-scroll-in-resize-mini-windows' as Gregory proposed? martin From unknown Sun Jun 22 07:48:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Aug 2021 08:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50178 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: ofv@wanadoo.es, 50178@debbugs.gnu.org Received: via spool by 50178-submit@debbugs.gnu.org id=B50178.162996559119376 (code B ref 50178); Thu, 26 Aug 2021 08:14:02 +0000 Received: (at 50178) by debbugs.gnu.org; 26 Aug 2021 08:13:11 +0000 Received: from localhost ([127.0.0.1]:48353 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mJAVa-00052R-Vu for submit@debbugs.gnu.org; Thu, 26 Aug 2021 04:13:11 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54300) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mJAVX-00052D-Br for 50178@debbugs.gnu.org; Thu, 26 Aug 2021 04:13:09 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54772) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mJAVR-0005Fq-De; Thu, 26 Aug 2021 04:13:01 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2623 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 1mJAVP-0004DW-VA; Thu, 26 Aug 2021 04:13:01 -0400 Date: Thu, 26 Aug 2021 11:12:38 +0300 Message-Id: <83ilzstyix.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <2acd8c0f-443e-3521-20a4-05369193b899@gmx.at> (message from martin rudalics on Thu, 26 Aug 2021 09:54:51 +0200) 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> <2acd8c0f-443e-3521-20a4-05369193b899@gmx.at> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: Eli Zaretskii , 50178-done@debbugs.gnu.org > From: martin rudalics > Date: Thu, 26 Aug 2021 09:54:51 +0200 > > > On true pixel-oriented systems there are APIs for querying the display > > engine about several metrics. Then you can place the text at certain > > pixel coordinates. Emacs, however, is a Frankenstein system, that uses > > pixels (on graphic frames) but the text positioning depends on previous > > text, i.e. for vertical positioning it is a line-based, not pixel-based, > > system. Therefore, when you just need to output some lines, you must > > deal with pixels, translate back to lines and, to add insult to injury, > > resort to post-facto information. > > Users think in terms of lines and columns. True pixel-oriented systems > are not convenient for editing. Yes. Most users won't know the pixel height and width of what we call "the canonical character" in Emacs. I only know that because I hack the display code (which works almost entirely in pixels) frequently enough to have those values burned into my memory, and even that only on my main development system. So the average users out there would be unable to specify dimensions in pixels, as the dimensions they have in mind are in lines and columns.