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: [PATCH] Support "\n" in icomplete-separator Date: Fri, 6 Nov 2020 16:15:41 +0100 Message-ID: <20201106151541.dpgep7borlja25su@Ergus> References: <20201105235735.oxouuek66ehu5o45@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="9311"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Andrii Kolomoiets Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 06 16:17:57 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 1kb3Uz-0002J4-5u for ged-emacs-devel@m.gmane-mx.org; Fri, 06 Nov 2020 16:17:57 +0100 Original-Received: from localhost ([::1]:60084 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kb3Uy-0008AE-8W for ged-emacs-devel@m.gmane-mx.org; Fri, 06 Nov 2020 10:17:56 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33912) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kb3TI-0007KF-S3 for emacs-devel@gnu.org; Fri, 06 Nov 2020 10:16:12 -0500 Original-Received: from sonic316-11.consmr.mail.bf2.yahoo.com ([74.6.130.121]:35271) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kb3TA-00053V-TN for emacs-devel@gnu.org; Fri, 06 Nov 2020 10:16:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1604675758; bh=JbUphla2k2nt5E3U7aLe3DbOT22GJAn8DdZjWSytj3Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=GDn2JURphg+2Ctxfl6H2YKF8H20R5fcCYJxUTcOEX0Tjz4df1gt8H4Cbc1Zdr9yuLEapszi5TRqzE9eCSh3cXtxjgnLf17BkMb87WmUgfmjdAcBRHH+lOwtBaGQR5aI7HxMKkiSI8lmssbbRBp9aUPSlrsvihQHJxQbzeJIrcJmbsm/DUJv5V0neLPB8Lh6gqSokNaONcuBr3zkExp4TgKNEcdyjWlfgmzqDwlRwAH83/8ZXQvle752aMNlu7NRRTqnUJBbvhd7U9u14/lnMJJVTv2TbBNbJfjddcrA6HGbyNOVb7upCWFqWPzBd56bJf9ZXBVkoCcWXd4kbXseEPw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1604675758; bh=l6m0MWWR8ABpkFrxV3DA+cv1+9OTmvFyLDMs8boShYr=; h=Date:From:To:Subject; b=sTOS9XSv6p2p6VBv7l4p0FbWUfoBE7bz65nqVstcmlKnrJIFvMYLU34HzvrMZpO15DoQpgAboAr6PEatm6s+zhJSXADCChkUoa5A0EN9bo5NBLTJRAFU5v2rdlhAukaau1E6LcbSUd+F1CtQAOH/D8U6B5OkQP+s4pLfJUM1Z/4FuuQXHob3inACgbrBmY8q+4fXf6ZJXWp5+vkbZNGeXUJ8aX/82G2e1PQxQAWwJAIQ9Ww44fHLtU5Njb4jXre4vxwc+9hcxgPTLhCOYdj1GefMdKnV6x50nCOW0l/nnY/fEP/AJVNEpT/cJ2LjOov70xX10slvr000qSADVOk15g== X-YMail-OSG: 0CNuQJ8VM1l1ymHPIQ6WBHDxKb6KUVraw6S7NwX2EGZDJM2PuG_atwF5muQ5cxP Z50qwTNCUH2nTkzCzBEFLtme6EzCrcYl27IKUIPonCLLrLqJFw3a_5XjwSlewnUOlwQu2773Ju7D 6xytdbX.zSRV9oIgyBG4kXL8Mqt6KYSotaed7ChdXZ7XAq8glz5MY9rloE5Trjb5EDt2OflJDrFY hUXmsV2gqtZZ5FR86UtJlqLE.74hz8XRnkRkCg2tFWkTJXhpqWGDNCxyEWRfWlvfOqo4NuJuI4Uw 0s7aNrHnXlBL7lfRmU76r7EDosRZeVI57npkLlflbRavLzKIPohnjHZoOgpdbBsK3nnRvfQsRB2s i9X6K2EF0yKJZOR6mJZEVQY1Xp.fKaGO1GWZLYmSiiG0_rc8.gxXyrH6YoaKHkZH5t1XAu735wT3 9XgqvOMi6.0bbBdH1Rl6mlJpAQ839hBoLBuZohVyEDD7jDnfGujf_s5brwzvNdRaxt494zkslmg8 7kfJ6G7Mm6SW_URKNBqmR6cVOg0Wb.nB4F0N4zSiHtBPP.qMjvZHNn0OisF4QXVLnUR5ISeK4Lvx x9oMMzGob_GzEHQLGn.Xr62av9kU5oBnK3SLG0ZykNfdSwJdHGkmjWyYHx8Pm8uQqhXEYIaZUSa7 kb2Og_diPbzrzzzEvxEvdbVTDGg7IVuFkhthmmCo.nxUO04Wob8VciXx7jMEvGdhOisXS_FYTCvF YcRw0PVL937ZXp8DX8kZx5xMpEZ0Cew03IgN.djFVLJE19.Ti7k3nGKVLFmZVRTLNfen6ElQUFjP 6hYg23wI4Dt4bY3XnLQLuN99J149JuK6lfTk6Syfns Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Fri, 6 Nov 2020 15:15:58 +0000 Original-Received: by smtp418.mail.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1d68e500c640a0d8e2034f7a0d19ea18; Fri, 06 Nov 2020 15:15:54 +0000 (UTC) Content-Disposition: inline In-Reply-To: X-Mailer: WebService/1.1.16944 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.8) Received-SPF: pass client-ip=74.6.130.121; envelope-from=spacibba@aol.com; helo=sonic316-11.consmr.mail.bf2.yahoo.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/06 10:15:58 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:258826 Archived-At: On Fri, Nov 06, 2020 at 02:36:14PM +0200, Andrii Kolomoiets wrote: >Ergus writes: > >> What you do in the patch is basically the same that is in the branch, > >IMO the key differece is that the patch doesn't do any calculation of >completions count based on line height, count of "\n" in separator etc. >I propose use the 'icomplete-prospects-height' value as the count of >completions that must be shown. > >Let's see how the patch deals with mentioned user requests: > Yes, I understand that; actually the height calculation was made because of this: ``` (setq icomplete-show-matches-on-no-input t) (icomplete-mode 1) (setq icomplete-separator "\n") (defface vmacs-minibuffer-font `((t :inherit default :height 1.3)) "The default font for minibuffer buffer. Monospaced font whihc is fixed idth and height is recommended." :group 'minibuffer) (defun vmacs-minibuffer-hook() (set (make-local-variable 'buffer-face-mode-face) 'vmacs-minibuffer-font) (buffer-face-mode t)) (add-hook 'minibuffer-setup-hook #'vmacs-minibuffer-hook) (setq max-mini-window-height 10) ;; add this line ``` in here: https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg01578.html Up to some months ago the pixel calculation was required because showing more candidates than fit in the minibuffer hided the prompt. There were long discussions related with that. Up to now there is a fix in the display engine, but I don't really know if we could totally ignore the max-height with that. Probably we could relax it a bit, but not totally. >> multiple \n in the separator > >(setq icomplete-hide-common-prefix nil) >(setq icomplete-separator "\n----------\n") >(setq icomplete-prospects-height 3) >(completing-read "prompt: " '("completion1" "completion2" "completion3")) > >Doesn't matter how many \n is in the separator. Just show 3 >completions. >See multiple-n.png attached. > This of course is supposed to work. But try with more candidates like 10 or so. In the branch I basically take the min between the icomplete-prospects-height and the number of candidates that fit in max-mini-window-height. >> using a different font size in the minibuffer > >Still show 3 completions, some text may doesn't fit in case the font >size will be too big. > I think that with the Eli fix probably we could relax at least this part a bit. >> display the completions in window-only frames like in mapple > >Thats actually why the patch was implemented. See, >maple-minibuffer-mode uses fixed frame height so the branch is show some >completions that fits based on frame-pixel-height. But mini-frame-mode, >which I use, uses resizeable minibuffer-only frame to show the >minibuffer content and the branch doesn't show any completions. >I mention this issue earlier: >https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00124.html > >In this usecase the patch behave better. > I can't reproduce the issue, that's why I didn't reply; sorry. In your use case I suppose it works "better" because the patch totally ignores the window height to fit; which, as I mention before, I am not sure is something we can do in the general case due to the prompt issue. If the prompt issue is totally away, we could; but I will need some confirmation from Eli or Stefan; but last time I tried it was still there. In any case if in your case it is broken, then we probably need another considerations. >> having a first candidate longer than a single line/occupying multiple >> lines > >Still show 3 completions, but minibuffer window may occupy more than 3 >lines. >See long-completions.png attached. > >Oh, link to mini-frame-mode if needed: >https://raw.githubusercontent.com/muffinmad/emacs-mini-frame/master/mini-frame.el > Best, Ergus