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.devel Subject: Re: feature/icomplete-vertical Date: Sun, 20 Sep 2020 20:43:36 +0300 Message-ID: <838sd4z6lz.fsf@gnu.org> References: <20200912133311.6ujtgczj6wyclufy@Ergus> <20200920130435.heye7bk73pm252km@Ergus> <83sgbczj0i.fsf@gnu.org> <83lfh4zfml.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40681"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joaotavora@gmail.com, spacibba@aol.com, casouri@gmail.com, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Sep 20 19:44:32 2020 Return-path: Envelope-to: ged-emacs-devel@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 1kK3O3-000ASu-Iq for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Sep 2020 19:44:31 +0200 Original-Received: from localhost ([::1]:40162 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kK3O2-0007j3-Ag for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Sep 2020 13:44:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48324) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kK3NF-0007JF-4m for emacs-devel@gnu.org; Sun, 20 Sep 2020 13:43:44 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38191) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kK3NC-0000tc-At; Sun, 20 Sep 2020 13:43:38 -0400 Original-Received: from [176.228.60.248] (port=3469 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kK3NB-0004kL-Mp; Sun, 20 Sep 2020 13:43:38 -0400 In-Reply-To: (message from Gregory Heytings on Sun, 20 Sep 2020 17:09:46 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:256261 Archived-At: > Date: Sun, 20 Sep 2020 17:09:46 +0000 > From: Gregory Heytings > cc: spacibba@aol.com, emacs-devel@gnu.org, casouri@gmail.com, > joaotavora@gmail.com > > >> trying to calculate the height of the completion candidate list, which > >> amount (as Stefan wrote) to redoing what redisplay does. > > > > I don't agree with Stefan, if this interpretation of what he said is > > correct. We have window-text-pixel-size to measure the size of text on > > display without redoing what redisplay does. > > > > Do you mean that every function which wants to display something in the > minibuffer should use window-text-pixel-size to create a text that fits in > the minibuffer without hiding the prompt? I didn't say that every function needs to do it, or anything to that effect. I was responding to the claim that measuring the size of text on display needs to redo what redisplay does. > And that this is better than only expecting such functions to approximate > the available space, and to rely on the fact that if the text is too large > the display engine will hide the end of the text instead of the prompt? I didn't say that, either, not in such a general form, anyway. I explained the state of affairs for the issue at hand in the bug report; if something there is unclear, I will happily answer specific questions regarding the issue we are facing.