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: About zcomplete Date: Mon, 21 Feb 2022 13:22:13 +0100 Message-ID: <20220221122213.ep2cel5fndq4bkq2@Ergus> References: <20220220040515.zum3iodtpscj23j3.ref@Ergus> <20220220040515.zum3iodtpscj23j3@Ergus> <87wnhp4wu3.fsf@posteo.net> <20220220132708.lvuzvg2fyfpp6k76@Ergus> <87y224v767.fsf@posteo.net> 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="19146"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, Juri Linkov To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Feb 21 14:36:00 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 1nM8r8-0004ls-SU for ged-emacs-devel@m.gmane-mx.org; Mon, 21 Feb 2022 14:35:59 +0100 Original-Received: from localhost ([::1]:51500 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nM8r7-0000nA-0X for ged-emacs-devel@m.gmane-mx.org; Mon, 21 Feb 2022 08:35:57 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55580) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nM7kQ-0000bu-Dl for emacs-devel@gnu.org; Mon, 21 Feb 2022 07:25:01 -0500 Original-Received: from sonic317-55.consmr.mail.bf2.yahoo.com ([74.6.129.110]:37543) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nM7kN-0005IP-Nq for emacs-devel@gnu.org; Mon, 21 Feb 2022 07:24:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1645446292; bh=FU0jXCyMxZWkNNyyme+4IlwYLOlfNBJYpk0nOFy8k6c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=YWi4sXU6/UOCGzafHC5zB9VMtWD57JfQ+zRsBNc+qBrZ6EVL/3hIIvU75lw9HkplmUjLhI2m8RjBAPopKdcFNh461SmlsmCXVvgMsDo22ec6iurI9Y2qpeWxAriy4ftCDj9aYaa+VafjwgAShXcRKl3dqRlXQh7DC1LS3u+XDKeHSnejYSmCkTJTKezUB3RQ9CC5LsFdisSzSHy2pMORp6g4plHGpMdZr0i0yOZHCW8OtatJVluJchPZgb1vNGA7OqvdII84aoEGL9n24JCE2PNMwWg3U3//3h5Ke8EBAr/lJF/wr7JnGOCrfF5jKLMmJbbK5GlYxNvrGL9Htnyq/g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1645446292; bh=EzOijsHGOdUDQZWOWIRoryt3lsB7wYMaY54lyecWFpk=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=sTCuQCvS1sUS2fBAE+jucP1iXGSOi/U7Q15EtHDjHI9pL/iydMKu2pZpmoTmVP2ExbUW7eCYQSygNuwCpCNABVdXdRecMzN9DYkcpvZFUpX/yveCKSBaQacrWEbodnVg943M/DGT+oQcmEDv/4J4jFNDE4ivtPe7MWI1FE8eB6msza6Ub32vXZZJPmTmXGDJGRPADifQ47EZyGqLoB9Jy9gpP4LdqVNyBby/uECDI7VLkncoMv0jhQ/PAMBMI6mtM8Lp87Nx51JqDUWeFFr8VckkcOpx/lzW0x2NUvbtAbXhs/yvQcxWgrI6jeH/uaCYGXSOUXNtivNiRhEk40Ycyg== X-YMail-OSG: 9UagBzgVM1lkTr98GFrYoAH1Mi6xySVbJAXWBD4qfR7vNA79G_S1vMK5vq0poIU gxfegTjX.c3FJ2f6wid_CSYJXvfnQ7X.I3MW.FV9k1CRttpVOFqAgKIIXVz4IalbYZAwL.z6l0Y1 _5tD3HZq04ts.W9.92Tmg.VI9Ifmb0OG6vg_WpCpQyEUxfkjfWitgsGk5Rfpx90V.wUXNxCHgvHQ GTCItA96GU7qoNVN0LZDn01ZLajHQvnqJxavmEyisp7EUOM2YAEnVgbqrrabXgGAAMvZP9gHenrJ u.444flG9rjxv8HBKkpaaGyhOrjEoLmfBoA42B9AP6mFpk.az6zTU2kHND.cJaldXea.zgwJ.Gvp g4k_T1nZZgdxb6FhLG7mOT8tJKPLjYY.N3fb6.SYfupJmfbDrS_Y8vKnE4m_2Pzygq7c03kKmDxw fquYjRJXejOYOxglOMQKFbHfcIB716aE3daWwC4oYpGQekXMGi83zfcay1ci_OeFfjKmY0RqXOvT V2DEPnDL2jzyuPvyFPu0jkEj_f7J4EjVTN8fz326ef2m.MiarqsQVWkmIZimxOtj7XTPHBH7tSOj kLBxOez6ifn5EygW6lZ.kTUFUwYMywMrJEzHkOSzGtAGs0SQwIf9DidEE_QQi0pFfmvPkBqJo_c8 Ius5PIBpWhMlqxbdzX1icIrF.SWEqvxvOrLfGOjQibXusxy_E6VPS1ZB6TWUajBKY20O0vW0jvWU TuIDhvZq_ySdiVHiJBfYCYrEAwrRj72QNhBH3YjwXrXDaQowHVcbOt0VeOouKfWWhbQGa6mqyBuA zZFrqSUGszWbrBn_X4kZNCsV9_N7KFFC5ywfTpiM76 X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Mon, 21 Feb 2022 12:24:52 +0000 Original-Received: by kubenode519.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 058611f415249c1da43aff377ece5552; Mon, 21 Feb 2022 12:22:51 +0000 (UTC) Content-Disposition: inline In-Reply-To: <87y224v767.fsf@posteo.net> X-Mailer: WebService/1.1.19797 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Received-SPF: pass client-ip=74.6.129.110; envelope-from=spacibba@aol.com; helo=sonic317-55.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:286559 Archived-At: On Mon, Feb 21, 2022 at 10:35:28AM +0000, Philip Kaludercic wrote: >Ergus writes: > >> On Sun, Feb 20, 2022 at 11:11:00AM +0000, Philip Kaludercic wrote: >> >>>When completion-auto-select was first added, there was a discussion >>>about adding automatic narrowing in the *Completions* buffer. Given a >>>mode like zcomplete, that decides to unbind all single-character >>>bindings, this might be possible (as an alternative to what you do in >>>zcomplete--try-on-minibuffer). >>> >>>Whether or not this should be coupled to removing the mode line of the >>>completion buffer is a different question. >> >> Actually a more `urgent` thing in my opinion may be to allow >> *Completions* to update without needing to narrow first. Then I could >> add a post-command-hook in the minibuffer to update *Completions* when >> it is visible. > >I am not certain what you mean here? Just to clarify, what I am >imagining is a isearch-like interface that updates the prompt and the >*Completions* buffer. > In the current implementation the *Completions* buffer is updated under tab 1) first tab completes common, 2) second one shows completions. If completions are visible then a first tab hides *Completions*, and then 1) and 2) Completions are only updated if the common part is completed and Completions windows is not visible. When we insert more text in the minibuffer with Completions visible what I do now is to hide the *Completions* window directly because they may be outdated. Calling the completion function in post command hook inserts more text in the minibuffer (to complete common), which is undesired. And the Completions are not updated if they are visible (at least I haven't found a way) >> With that we only need a highlight and the zsh experience may be almost >> done with minimal changes. > >I am unfamiliar with zsh, how does it differ from say bash? > In zsh 1 tab completes common and show completions candidates (may be configured to do in the first tab or wait for a second one, but we don't really care). The key difference is that with completions visible if we type a new letter then the completion list updates immediately and if there is a common part is only completed with a new tab. >>>This should probably be reverted when zcomplete-mode is disabled. >> >> Agree. But we need to cache the original value tho... I have been >> thinking to implement a general solution for that issue similar to >> connection-local-variables, because it is a general issue many packages >> need to deal with. > >I guess this is only of the issue that is so easy to solve on a >case-by-case basis (e.g. by setting a symbol property) that nobody has >bothered to write a general solution (e.g. by adding a keyword to >define-minor-mode that specifies what variables/user options to set when >enabled). > Look at issue #54074 and Juri's comment. I actually find that this is a very common and repeated issue and duplicated code in many packages around... >-- > Philip Kaludercic Best, Ergus