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: Mon, 05 Oct 2020 11:54:36 +0000 Message-ID: References: <20200912133311.6ujtgczj6wyclufy@Ergus> <20200920130435.heye7bk73pm252km@Ergus> <83sgbczj0i.fsf@gnu.org> <83lfh4zfml.fsf@gnu.org> <838sd4z6lz.fsf@gnu.org> <20201001164804.mqqyxtet4ttweuyv@Ergus> <83blhhdy3w.fsf@gnu.org> <87d01xghmt.fsf@gmail.com> <83sgatc8er.fsf@gnu.org> <83mu11c78j.fsf@gnu.org> <87tuv9eygk.fsf@gmail.com> <87imbogb6k.fsf@gmail.com> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1766"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: Eli Zaretskii , emacs-devel@gnu.org, casouri@gmail.com, spacibba@aol.com, juri@linkov.net To: =?ISO-8859-15?Q?Jo=E3o_T=E1vora?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 05 13:55:38 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 1kPP5d-0000JU-ES for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Oct 2020 13:55:37 +0200 Original-Received: from localhost ([::1]:39756 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kPP5c-0008JX-Bw for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Oct 2020 07:55:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54264) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kPP4u-0007q5-4k for emacs-devel@gnu.org; Mon, 05 Oct 2020 07:54:52 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:58531) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kPP4q-00018S-BL; Mon, 05 Oct 2020 07:54:51 -0400 Original-Received: from sdf.org (IDENT:ghe@otaku.sdf.org [205.166.94.8]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 095BsdII000946 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 5 Oct 2020 11:54:39 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 095BsxbD007028; Mon, 5 Oct 2020 11:54:59 GMT In-Reply-To: <87imbogb6k.fsf@gmail.com> 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/10/05 06:53:34 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:257112 Archived-At: >> This is feasible, but IMHO very (and needlessly) difficult. Basically >> you need to work with pixel dimensions, and recalculate everything >> manually: first calculate the (maximal) size of the miniwindow (given >> the user preferences, in particular max-mini-window-height), then >> calculate the size of its contents with window-text-pixel-size. You >> should add one character (or line) at at time, and recalculate the new >> size each time. > > Yes, as far as I understand, in the general case, it must be one > character at a time, since each character might have a different pixel > width. At some point there is a cutoff and things are not displayed > anymore. I was hoping that that knowledge, which is held somehere in > the system at some point, could be imparted to the application. > > Anyway, whatever the mechanism (notification or painstaking > calculation), we should first write a function that does this. That is > the bugfix in my opinion. Then we can work on simplifying that > function's implementation, if it turns out to be slow or problematic. > There is no need to calculate anything with the "start-display-at-beginning-of-minibuffer" solution I sent a few hours ago. Emacs does everything for you, at no cost. Or is there something that you need (e.g. for Eldoc) and that this solution does not do?