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: feature/icomplete-vertical Date: Sat, 19 Sep 2020 12:47:27 +0200 Message-ID: <20200919104727.3dt22ksu34t25ylp@Ergus> References: <20200919015957.prffuac2jke3hp6a@Ergus> <20200919061531.oyjlbdvkbeif5fsg@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="31790"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 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 Sat Sep 19 12:48:23 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 1kJaPm-0008AF-DV for ged-emacs-devel@m.gmane-mx.org; Sat, 19 Sep 2020 12:48:22 +0200 Original-Received: from localhost ([::1]:41584 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJaPl-0002XM-FZ for ged-emacs-devel@m.gmane-mx.org; Sat, 19 Sep 2020 06:48:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55632) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJaP3-0001xU-F0 for emacs-devel@gnu.org; Sat, 19 Sep 2020 06:47:37 -0400 Original-Received: from sonic307-1.consmr.mail.bf2.yahoo.com ([74.6.134.40]:34799) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kJaP1-0003yf-8u for emacs-devel@gnu.org; Sat, 19 Sep 2020 06:47:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1600512453; bh=VlCqVvWUr5QxZS8G+2EAUZXsTtKqWBoRixzuJR0JcY8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=LGzBZNtERxzQFW6zLnso8Ry0tyNbJMhkgOMTmjk3TQOI4CQF47J26Z11EoOgM4DpHKli1B4e2L24xKBX3fkWKbsb5CrLNVKKEyDJbQQ+c+j02N22RUTjRZVWtkzcRr3exa1wVMlLd2LRxBswSsnnKcRxshwkOrILTTVGpAyyq5+eY0UQtw8GodlMWcJ1uWWE9Xt82Avkn+YR0OBukW1H0fMrdNt87vFLLgGnLCdsMrOL0t3N9VD1HtMxPMJBYjeMEeKarGnIwOMPKWxQs3DdkXYRCnDrQxrkCpeIYpgntNGj1Ia3tVoAGfPGsy3d+dyI8sMcguk+nGa4GZpiCBwQkg== X-YMail-OSG: .SyRH74VM1ms8yk2PczUxpzWxO5vjQWmquJRS3cc.yJoaZUHnNuDw7gt1bMKxwL bRh2Gx8eTuMMOU6zzZI1uT7_pam5cc.woS7CgcWIjjEpWdSq_xAFtIpuGDWVXNQvDEuMdFQxVhvN _UzcUXhJzPfN2Zyh7JYDhr5wMHT62dNlpKNsb8PMtdt2MIuMKuzsxnBgWZDf2rKe3tlc.NdzfVt1 SMZAzRuVMCTwgzD_s39zmcH.qWYIIpAzswQ7Eoh0HmFOyqoFLKhkR9uygogwpc.hQMACSzmr.qiQ 0d.Mcn5gKHZJl3dc79dG3NdDHxoBbmUpacMErbMqGOVUV2H6v5Dd_Lw0R_Vylq6cmdnfj9B1BIWs l17RwAISAa4Dj5xac0JfD__Sk9PIwv6ZD1NAQ_fsbpUx_8XU6AnoURLQo9eOxxeycQOnlAr5Q9ua VKvpSu9QqvshYcWh6EcfGTovyYOjby_5mmaf5KkwFIdWQbtRsyMZjmxxvvOtHMZqeSHMmok0bxGx o_sRXWFlBr933VdjOZ2Mj4l3PfB1JL18ULFRuvLul771qYmawFpoqlVxwRG3wBsYwGMEFw8R31IK QOCMo5lti2vpTfxS5sbUIbSxujWPajrA.TOZe0jQ_k0g3perBL2OC3zDc7aR8QMbBQdFYL4MzBlW 7jLgHGHxdaYaqDe_RjTiMeoQ2rYpg5xCDZDmLWXFE5sK.iAM3H7TU11ZPNPkgxZVuD4VIkquEXQv wEXy03osiroqNCr5tOpWCXNw2ahOw43MvFmalfia74ujT0L.4T1gk58EYydqQ3dfW3ng21FPZ5Z1 M7oQnB0b_V4XAiyeL3EtHOtg7loD6nDbLQGDpJ.Lvi Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Sat, 19 Sep 2020 10:47:33 +0000 Original-Received: by smtp414.mail.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b20c381f6dc2b7241dc7d1b7754b73d6; Sat, 19 Sep 2020 10:47:33 +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.134.40; envelope-from=spacibba@aol.com; helo=sonic307-1.consmr.mail.bf2.yahoo.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/19 06:47:34 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:256156 Archived-At: On Sat, Sep 19, 2020 at 08:35:24AM +0000, Gregory Heytings via Emacs development discussions. wrote: > >> >>There is another corner case that is when >> >>(frame-parameter nil 'minibuffer) is 'only. This was also a problem >>reported some days ago needed when using frames and not the >>minibuffer. >> > >Hmmm... in that case (a corner case, indeed, which does not seem to be >covered by the current icomplete implementation), it means that the >minibuffer is not resized att all? TBH, it seems to me that using >icomplete with a minibuffer-only frame does not have much sense. > Some users of maple-minibuffer-mode uses them with icomplete + the external package. >That being said, it is always possible to imagine more corner cases, >for example a completion candidate that would fill more than one line, I know, for this the users set visual-line in minibuffer. Which I probably will do to. >or a completion candidate list with different fonts (I'm not sure that >this is actually feasible) This is the reason of the "format" approach I was trying; and why working directly in pixels as it is simple to get the current line height in pixels too and increment it more precisely. But I consider this as a different feature too, so it is not in that patch. >, or completion candidates with embedded newlines, or... Covered with the format approach too, but also a new feature. > >> >>The other problem with the patch is that due to rounding and floor >>when using different fonts there is too much extra space missing and >>sometimes missed a candidate at the end. This was also reported some >>days ago. >> > >I don't think so, but I could be wrong. I tested my code with many >different parameters, and did not see the "extra space" you mention, >in all cases the completions fit perfectly in the minibuffer, and the >prompt is never hidden. > Or I could, but I had issues before with this before. >> >>Look at the attached patch as it is partially simplified in my local >>branch. >> > >Thanks, I'll have a look. > >Gregory >