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: Wed, 25 Aug 2021 12:49:39 +0200 Message-ID: <87k0k9er3w.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> <871r6ig01r.fsf@telefonica.net> <83wnoavftn.fsf@gnu.org> <87wnoaeisl.fsf@telefonica.net> <83sfyyuupx.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="40564"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 50178-done@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 25 13:12:28 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 1mIqpY-000AN1-0f for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 25 Aug 2021 13:12:28 +0200 Original-Received: from localhost ([::1]:56488 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mIqpW-0001XF-Ve for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 25 Aug 2021 07:12:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51056) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mIqTq-0001pJ-H5 for bug-gnu-emacs@gnu.org; Wed, 25 Aug 2021 06:50:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34317) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mIqTq-00062h-92 for bug-gnu-emacs@gnu.org; Wed, 25 Aug 2021 06:50:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mIqTq-0003b4-7o for bug-gnu-emacs@gnu.org; Wed, 25 Aug 2021 06:50:02 -0400 Resent-From: =?UTF-8?Q?=C3=93scar?= Fuentes Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Aug 2021 10:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 50178 X-GNU-PR-Package: emacs Mail-Followup-To: 50178@debbugs.gnu.org, ofv@wanadoo.es, ofv@wanadoo.es Original-Received: via spool by 50178-done@debbugs.gnu.org id=D50178.162988859213800 (code D ref 50178); Wed, 25 Aug 2021 10:50:02 +0000 Original-Received: (at 50178-done) by debbugs.gnu.org; 25 Aug 2021 10:49:52 +0000 Original-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 Original-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 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 4GvjR820KYzdcRw; Wed, 25 Aug 2021 12:49:39 +0200 (CEST) In-Reply-To: (martin rudalics's message of "Wed, 25 Aug 2021 09:49:11 +0200") 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-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:212602 Archived-At: 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.