From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing Date: Tue, 24 Aug 2021 21:13:08 +0300 Message-ID: <83y28qvhhn.fsf@gnu.org> 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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3568"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 50178@debbugs.gnu.org To: =?UTF-8?Q?=C3=93scar?= Fuentes Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 24 20:14:09 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 1mIaw5-0000ib-3R for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 24 Aug 2021 20:14:09 +0200 Original-Received: from localhost ([::1]:58272 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mIaw4-00084o-1y for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 24 Aug 2021 14:14:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44650) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mIavy-00084g-PL for bug-gnu-emacs@gnu.org; Tue, 24 Aug 2021 14:14:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33630) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mIavy-00028e-Hw for bug-gnu-emacs@gnu.org; Tue, 24 Aug 2021 14:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mIavy-0004h1-DV for bug-gnu-emacs@gnu.org; Tue, 24 Aug 2021 14:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: 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 Original-Received: via spool by 50178-submit@debbugs.gnu.org id=B50178.162982880317981 (code B ref 50178); Tue, 24 Aug 2021 18:14:02 +0000 Original-Received: (at 50178) by debbugs.gnu.org; 24 Aug 2021 18:13:23 +0000 Original-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 Original-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 Original-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 Original-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 In-Reply-To: <875yvug2ka.fsf@telefonica.net> (message from =?UTF-8?Q?=C3=93scar?= Fuentes on Tue, 24 Aug 2021 19:44:37 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:212567 Archived-At: > 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.