From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: resize_mini_window question Date: Fri, 18 Sep 2020 17:56:38 +0200 Message-ID: <20200918155638.bvak6p3ewdqjmdgj@Ergus> References: <20200918150113.4vz5vq3krfslrwdz.ref@Ergus> <20200918150113.4vz5vq3krfslrwdz@Ergus> 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="4956"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, Eli Zaretskii To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 18 18:02:40 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 1kJIqM-00018r-Ji for ged-emacs-devel@m.gmane-mx.org; Fri, 18 Sep 2020 18:02:38 +0200 Original-Received: from localhost ([::1]:54518 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJIqL-0008G6-Jz for ged-emacs-devel@m.gmane-mx.org; Fri, 18 Sep 2020 12:02:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33448) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJIkm-0001s1-6X for emacs-devel@gnu.org; Fri, 18 Sep 2020 11:56:52 -0400 Original-Received: from sonic308-2.consmr.mail.bf2.yahoo.com ([74.6.130.41]:35799) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kJIkj-0000j7-1L for emacs-devel@gnu.org; Fri, 18 Sep 2020 11:56:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1600444607; bh=RqYOYd7nMloLpFBN+AzZUJS8W6CXtRUXWL8VqoVJTis=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=W9qVe7yPrMiO3TZEZxkMI47BH99Q010uq3dNAQU3DPub0b+r3I6iCCPdTN0L4lBbTym0Q/kSIe8EvHBtWohOVqGaKqLpV26L8b0zQGkUesWiYjtrdJawmVs+oGOtMaTq+3nUW5CAwraB/EKQF+NwZORCbwVpQQD4GdE31tzdYndjUh/wXTQFhzdJ8jzqDkEAQvHwzmsHyb2lGCSyI9CKF51GUEgPSPeiiXOPUux//DVJq+QwIfw29rkOigAWjeto1pLwQQEIyC88Elb9JryTPkJmlion/QsLO2JoIUUguXwYGzDCKbU9sbWbztanR/ru1U1/d/dLvNYWwmRPKUxHsA== X-YMail-OSG: OiTRnMMVM1mgpUMtzUQP5RCWaeDdREcx7wAk8xTBhxHU1a0cKJrOgr3HvdCjw7e N5NwAV7TcWsntdTINh_7o67ryPnD40JhUaV3PgTSFmePErx6Buzuv_m4f61_WCZIZ90GFT9AjMXI SDJCndwFl11FzMhFK.9LBK3kxmxv8jtiAWwEH2fX8sToTrGx90_UpUVCgb6xu4QB9.8CY9zCvI8e 4ADLJBEqwFQJggyC98xMCl4HMs2Jusg1Ace.D6B5.UimmAA.6sH3eJFcEV9WnJwHDJdZkBjEw7Qy teM54B1gfZNVeZc7bESAKKR28noeYzlmlNxQYu8OjGcdaHn8e_4iq2R0_TBfZQ8gW3y9xLOTQXZi tR9ctKFocgvIBmTJnBx0_W7ufoEobCUjoMNhM1USrXojcg9CFpWIEPUvtiY5je4y2u01PlUXSIwq POv8_HP3_9XkpwvkJfwvDMkw1so3.m6ZYY7ENYRCXrBZRRO8kPnAmuzV5ls6T.tzqrKexGIfPHir VDZynmWko4yW4Xus9yJDBGzinz7HYs7bD9khzxviMh7k0WZ26XijYZA9stoiDM8E0R8NXuAH02iC VJIhPzFQgqMoZcObn7jOOpsxsf1ANNdhEkxMkApfEgrKV0Sd3YrjTep4U0AE6bhUrHZQDEpzQyCs oxbwegrBHueC7WQNPd8Rei58DQ7smFj8y_.FSPILV6_rKdNMqZyfcWTEUlD9cy9n3ZOBu6xoJyYi Bn4p79VJC1yBXGNfS_hjqEmZQDgXOtq4nN1DIMCm66v_E7ZoOhElM6smNYm8m_srAMyjYhXASeq3 DrPPd2ivvse1UBKyL2UuEecpWCWHulhzfsUgx6aQvM Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Fri, 18 Sep 2020 15:56:47 +0000 Original-Received: by smtp417.mail.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7ecb7e8951e0fe63454fa93e48b11a59; Fri, 18 Sep 2020 15:56:45 +0000 (UTC) Content-Disposition: inline In-Reply-To: X-Mailer: WebService/1.1.16583 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Received-SPF: pass client-ip=74.6.130.41; envelope-from=spacibba@aol.com; helo=sonic308-2.consmr.mail.bf2.yahoo.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/18 11:56:47 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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:256109 Archived-At: On Fri, Sep 18, 2020 at 11:30:58AM -0400, Stefan Monnier wrote: >> I see 3 possible clean solutions: >> >> 1) Modify resize_mini_window to use the minibuffer's font size to >> calculate the height when Vmax_mini_window_height is an int. (don't know >> if it is possible to access the minibuffer font size from there or if >> this could produce some undesired side effect) > >I don't think this will work reliably, e.g. even if your minibuffer only >has N lines of text, line wrapping different fonts used for different >scripts, plus overlays and text-properties applied to specific parts of >the minibuffer's content will make that computation fail to give the >desired result. > I think that in minibuffer this is not the most frequent case but I get your point. At least if we do check buffer-face-mode-remapping from C could give a more accurate value. But maybe it doesn't worth it. >> 3) Just force the text to fit ignoring that the number of real visible >> lines will be different than max-mini-window-height. > >It might not even be possible anyway if the minibuffer's content uses up >more space than available in the frame. > >> (This will be seen as ignoring the max-mini-window-height) > >Indeed, which is another problem with this option. > >> 2) Modify the documentation of max-mini-window-height to specify that if >> an integer, it specifies a number of lines respecting to the frame's >> default font, not the minibuffer's visible lines. > >That sounds good. It's not sufficient to fix the problem in >`icomplete-vertical` obviously, so `icomplete-vertical` would need to >be changed. Maybe it could check the `window-end` to detect when the >minibuffer's content is larger than what fits and shorten >it accordingly? > > Yes I know. The problem with this was that in my case the user could be expecting to see as many lines as specified in max-mini-window-height as an integer. The external package used to force an enlarge-window but I feel that this is somehow a workaround. > > Stefan >