From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: feature/icomplete-vertical Date: Sun, 20 Sep 2020 17:09:46 +0000 Message-ID: References: <20200912133311.6ujtgczj6wyclufy@Ergus> <20200920130435.heye7bk73pm252km@Ergus> <83sgbczj0i.fsf@gnu.org> <83lfh4zfml.fsf@gnu.org> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21650"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: spacibba@aol.com, emacs-devel@gnu.org, casouri@gmail.com, joaotavora@gmail.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Sep 20 19:11:11 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 1kK2rm-0005X4-2P for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Sep 2020 19:11:10 +0200 Original-Received: from localhost ([::1]:40552 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kK2rl-0002Lw-5F for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Sep 2020 13:11:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42984) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kK2qg-0001pr-Ba for emacs-devel@gnu.org; Sun, 20 Sep 2020 13:10:02 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:62975) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kK2qd-0005ID-9V; Sun, 20 Sep 2020 13:10:02 -0400 Original-Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08KH9nJB003614 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sun, 20 Sep 2020 17:09:49 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 08KHA35F010030; Sun, 20 Sep 2020 17:10:03 GMT In-Reply-To: <83lfh4zfml.fsf@gnu.org> Received-SPF: pass client-ip=205.166.94.24; envelope-from=ghe@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/20 13:09:56 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:256260 Archived-At: >> 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? 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?