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 20:38:56 +0200 Message-ID: <871r6ig01r.fsf@telefonica.net> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11878"; 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 20:40:21 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 1mIbLQ-0002p7-DQ for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 24 Aug 2021 20:40:20 +0200 Original-Received: from localhost ([::1]:33124 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mIbLO-00030x-IN for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 24 Aug 2021 14:40:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49248) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mIbL9-00030l-1A for bug-gnu-emacs@gnu.org; Tue, 24 Aug 2021 14:40:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33672) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mIbL8-00039K-3M for bug-gnu-emacs@gnu.org; Tue, 24 Aug 2021 14:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mIbL8-0005Nv-0b for bug-gnu-emacs@gnu.org; Tue, 24 Aug 2021 14:40:02 -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 18:40: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.162983034420624 (code B ref 50178); Tue, 24 Aug 2021 18:40:01 +0000 Original-Received: (at 50178) by debbugs.gnu.org; 24 Aug 2021 18:39:04 +0000 Original-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 Original-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 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 4GvHv501zQzdbJZ; Tue, 24 Aug 2021 20:38:56 +0200 (CEST) In-Reply-To: <83y28qvhhn.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 24 Aug 2021 21:13:08 +0300") 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-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:212571 Archived-At: 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.