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: [PATCH] Question about completion behavior Date: Wed, 9 Mar 2022 17:14:53 +0100 Message-ID: <20220309161453.g3ta6sd2xqzvwcgr@Ergus> References: <20220309001013.gxyh2uasbuxiz6ww.ref@Ergus> <20220309001013.gxyh2uasbuxiz6ww@Ergus> <20220309014619.bptamkv47xdiyhzp@Ergus> <831qzbg5j2.fsf@gnu.org> <20220309101159.4k3uma2ztvldlqiz@Ergus> <20220309114654.zq3h3u47btmt7q2u@Ergus> <83tuc7e066.fsf@gnu.org> <20220309143016.n2q3u25gat6plaxz@Ergus> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="jac3uxbrckprvpcb" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13376"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Mar 09 17:17:53 2022 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 1nRz0b-0003Gw-OH for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Mar 2022 17:17:53 +0100 Original-Received: from localhost ([::1]:50950 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nRz0a-0003Ts-7a for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Mar 2022 11:17:52 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35132) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nRyyV-0002Uc-7y for emacs-devel@gnu.org; Wed, 09 Mar 2022 11:15:43 -0500 Original-Received: from sonic311-14.consmr.mail.bf2.yahoo.com ([74.6.131.124]:34484) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nRyyS-0001Iq-E5 for emacs-devel@gnu.org; Wed, 09 Mar 2022 11:15:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1646842538; bh=vShlyFuI0aWPYiiSM+hTwFi53T/wQq8k6DXHqxilLjg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=VKV7mSPsaqJXbPUoKP9tTyE4z8dC8C9EXeI1En8G9wyMKu+BEKbmJZHuzZd0QMgPzgVAE0t4iFODdI/zml1Gbcn0aqmXtA0i4isbOdA6foP9IB8hld/l/IdMKMG9gIsfwaQSxq2n25hr90AN8HLKIA58+EyDp5cuGbEdXgq810xkVLGM8abThJ4zIG2cpL8Bdcz2G9TY+IGlXSh22qNHH9xA5Rjrz73cDabrRi+XCyM0U+wQJEhOOoBevTT5L3Ph2RWiFs0cSajo+5fCMtEi3b7VMmze3/DsTWp1QzE+guZKL0ZU2tSKSr/cC5lbCbU007ESCmPSrmw+1/iJVI43yw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646842538; bh=16cYxN/98/gh3l22e52Cxh54HB678ehw2zOryW6B6el=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=YAn9y465U2Lpdo4FXc/ODB8x33zRDW5cIEEw9ccvwMu0QyMxE/b+nsXqkp/P7XdgpkNHOMwfAjuwtJ/dRJ0HtS/ViU9mPnQOyUP1Jmi0SWcMdbuMtx4wi+J6FbQbgWv1RFvLT6hurZcQFyLBzArqDh9AySxxKD1UTpl84nF32spnN2Mp7C1iAXNQkrNCtiwOh4RUHPvBqKA8JpKP9VDrfR8nEgSWax5HlY6Pp4iXT4UhPeIPE6ZJl717ZGanTBnjIUNLgEdr981r9Gpaba1XVNLLYwuhom+Vl5yUROgmx6P9Z//1hhIeaFz6vNx404fN1JPDBuXTDicS3AZ42hyhqQ== X-YMail-OSG: 5rcUDz8VM1lv3jLD11UTZFbiGY1MNwYUZ89JwaxgnE4VoC.MD84fgotdrVdOUzd BtiQ.Ojy__T51grihm09vJK2ooAE9_J7MESq4Omj7l1FmggJUVnxO61g72a4NpqujoZBWqQVLFyX X7j9blqdc9EWkb9oVQ3z3UdnvwLmLEWaw1eHTqba9WsLfGgxgJiuXCTpL5L0h577zUU7D2_9paeb iu4OmogRzzOhxU93G.itJucplc0SfXirL.lP9c_Jjzx7c.I5GxrzcLs7cGk1Hdd7hLpQw68aVD4I CcicOsnxFCF1h8DaFSnkICP3S0qxxr1AO5_fR3fOqF34lMhapqS0tZtG6ifH_LlukDK8iSbRV0bt dImcWmwjgvaWIC88r4qrKVGeC3xFhcN26y8uK_UaFqLvU_glz0GcbfshhkAcwoPfhTJbH8bW075M tZG_XDq1RCUht0d52VUcptPz.rzck95aeieI3ErsncM_2SNWzqiSOzgoiaOAfuPvCrju8BDfslVb ZRFWfdlyWqaB.eHBySz3oBE4lr5kdc6ie4ofcWu7GpcS1fI3Hq.6O6RCiR50VKjxRkFjEIy651UT GwhI3Xk6_OLMgJWkIoYQa1xVcScZcTOdC5AajXYD7DCK_Mxzh3Ml28GjlANYNUQet.4hxluq.Piu DFY29MBWg.dn4buJa88uho740GZNL8bD3tAFhcUVRs0wfPsjHH0XbTQqAcQGtB_wqpFfBeriGV56 aw6rcke41SCsjcXuEveP3_0B_YaswrtrtWSIQ8fYZncFjzbtxw5l1OqBdJggekEiekMWCYkyW_z_ gYoLniPmSlsR.8g7I8m5keoKJDPanBfsAXF1tyy0rY X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Wed, 9 Mar 2022 16:15:38 +0000 Original-Received: by kubenode507.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e7d8826894805653b2cea547bc2ca71e; Wed, 09 Mar 2022 16:15:33 +0000 (UTC) Content-Disposition: inline In-Reply-To: <20220309143016.n2q3u25gat6plaxz@Ergus> X-Mailer: WebService/1.1.19878 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Received-SPF: pass client-ip=74.6.131.124; envelope-from=spacibba@aol.com; helo=sonic311-14.consmr.mail.bf2.yahoo.com 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, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:286961 Archived-At: --jac3uxbrckprvpcb Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Please give a look to the attached patch... It adds two new values: visible: to update when visible else do nothing (as Stefan suggested). always: to always update or show completions (Like bash show-all-if-ambiguous) BTW: the lazy value is more like show-all-if-unmodified i think On Wed, Mar 09, 2022 at 03:30:16PM +0100, Ergus wrote: >On Wed, Mar 09, 2022 at 03:16:17PM +0200, Eli Zaretskii wrote: >>>Date: Wed, 9 Mar 2022 12:46:54 +0100 >>>From: Ergus >>>Cc: Stefan Monnier , emacs-devel@gnu.org >>> >>>Look at the attached patch, it may need some small improve to solve the >>>case 4. but so far it gives a consistent behavior with any value of >>>completion-auto-help (and it is actually simpler than the current code) >>> >>>Alternatively we may add another custom, something like: >>> >>>completions-on-complete-action which may have 3 possible values: >> >>We don't need a new option, we can add a new value to the >>completion-auto-help. >> >>But yes, I think this behavior you propose _must_ be optional, most >>probably opt-in for starters. Not everyone will want it. >> >>See also completion-cycle-threshold: this new behavior should not >>tramp that option. > >I tend to agree Eli, but actually I started a thread because the default >behavior is indeed inconsistent with completion-auto-help as the same >Stefan mentioned. > >The current behavior mixes the completion-auto-help==t with >completion-auto-help=='lazy when there is some completion and the >completions are already visible (hiding them). > >If we do: > >compi it should be completed, but if the completions list is >somehow visible, then after the tab it is not correct, so we currently >hide it, when we must just update it right? > >The fix in any case is extremely simple and I think that with a new vale >for completion-auto-help to 'always it will work, but may be even >complicated to explain in the documentation... > > --jac3uxbrckprvpcb Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="completion_custom.patch" diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 36b8d80841..c6a803cbc4 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -898,7 +898,11 @@ completion-auto-help is requested but cannot be done. If the value is `lazy', the *Completions* buffer is only displayed after the second failed attempt to complete." - :type '(choice (const nil) (const t) (const lazy))) + :type '(choice (const :tag "Disabled" nil) + (const :tag "Enabled legacy" t) + (const :tag "After a second attempt" lazy) + (const :tag "Visible update" visible) + (const :tag "Always update" always))) (defvar completion-styles-alist '((emacs21 @@ -1343,16 +1347,19 @@ completion--do-completion (completion--cache-all-sorted-completions beg end comps) (minibuffer-force-complete beg end)) (completed - ;; We could also decide to refresh the completions, - ;; if they're displayed (and assuming there are - ;; completions left). - (minibuffer-hide-completions) - (if exact - ;; If completion did not put point at end of field, - ;; it's a sign that completion is not finished. - (completion--done completion - (if (< comp-pos (length completion)) - 'exact 'unknown)))) + (cond + (exact + ;; If completion did not put point at end of field, + ;; it's a sign that completion is not finished. + (minibuffer-hide-completions) + (completion--done completion + (if (< comp-pos (length completion)) + 'exact 'unknown))) + ((pcase completion-auto-help + ('visible (get-buffer-window "*Completions*" 0)) + ('always t)) + (minibuffer-completion-help beg end)) + (t (minibuffer-hide-completions)))) ;; Show the completion table, if requested. ((not exact) (if (pcase completion-auto-help --jac3uxbrckprvpcb--