From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?=C3=93scar?= Fuentes Newsgroups: gmane.emacs.bugs Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Date: Tue, 24 Aug 2021 19:44:37 +0200 Message-ID: <875yvug2ka.fsf@telefonica.net> References: <87eeajfvbq.fsf@telefonica.net> <83a6l7vyu2.fsf@gnu.org> <87a6l7ezks.fsf@telefonica.net> <837dgax1a0.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17921"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 50178@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 24 19:45:12 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 1mIaU3-0004Nt-GB for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 24 Aug 2021 19:45:11 +0200 Original-Received: from localhost ([::1]:46078 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mIaU2-00074C-2U for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 24 Aug 2021 13:45:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39376) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mIaTu-00072p-5g for bug-gnu-emacs@gnu.org; Tue, 24 Aug 2021 13:45:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33590) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mIaTt-0007Z5-U4 for bug-gnu-emacs@gnu.org; Tue, 24 Aug 2021 13:45:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mIaTt-0003we-Qm for bug-gnu-emacs@gnu.org; Tue, 24 Aug 2021 13:45:01 -0400 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 50178-submit@debbugs.gnu.org id=B50178.162982708615125 (code B ref 50178); Tue, 24 Aug 2021 17:45:01 +0000 Original-Received: (at 50178) by debbugs.gnu.org; 24 Aug 2021 17:44:46 +0000 Original-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 Original-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 Original-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) In-Reply-To: <837dgax1a0.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 24 Aug 2021 19:20:23 +0300") 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-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:212562 Archived-At: 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.