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: Select completions from the minibuffer Date: Tue, 22 Mar 2022 16:21:50 +0100 Message-ID: <20220322152150.xnghbiufg6fvspio@Ergus> References: <86r1773sb4.fsf@mail.linkov.net> <87pmmquew4.fsf@gnus.org> <86h7817mj4.fsf@mail.linkov.net> <87ilsgx5fx.fsf@gnus.org> <86bkxz3y1h.fsf@mail.linkov.net> <875yo7p0hh.fsf@gnus.org> <86v8w675un.fsf@mail.linkov.net> <837d8mf6pf.fsf@gnu.org> <20220322141815.2iq7jec2d5lvfox3@Ergus> <831qyuf3e0.fsf@gnu.org> 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="1435"; mail-complaints-to="usenet@ciao.gmane.io" Cc: juri@linkov.net, larsi@gnus.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 22 16:23:48 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 1nWgMN-00008S-QB for ged-emacs-devel@m.gmane-mx.org; Tue, 22 Mar 2022 16:23:47 +0100 Original-Received: from localhost ([::1]:52156 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nWgMM-0007ft-SC for ged-emacs-devel@m.gmane-mx.org; Tue, 22 Mar 2022 11:23:46 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34398) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nWgLE-0006jW-Gp for emacs-devel@gnu.org; Tue, 22 Mar 2022 11:22:36 -0400 Original-Received: from sonic310-14.consmr.mail.bf2.yahoo.com ([74.6.135.124]:43930) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nWgLB-0005wK-N3 for emacs-devel@gnu.org; Tue, 22 Mar 2022 11:22:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1647962552; bh=h79Js8bIZrKvSN+16JL1zFUHV1IhPksTylTHqVISKxM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=SjBFNB29YCrbcAgLTdnSrk4X2v2+I+ocoA1zDRfb4+3NDD485g4ct1i/nxKaRhW711Z3f9ft6ZYO0hkAzN4iLe6FOVCpZTaEEu78fW6pxE1ec9eGwNGFAJHhBjLH2hg8fi0Xtv3k9cRdCVzTyWfTiWNh1GSqc8Q51+uAV/IQuf1OXopYVwLLLyXlePYScvXFDd7z701203vOO5IC2pAAZQXYzvszB6VTLUMjzw711sIbQl2cQwfP1dM/ZzYPRMQYD6M1GCwXG88Ou1NHTOKNhLdEq1lbWpCCHF3Bmwt5VRrl5mlp24eKFuiSpQOuyYNfGfAFsyM3XdA6C1MvWDkj+w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1647962552; bh=LVk9/fYKUJ154Qitd1+u5bgrRn8we0HbsAT1+gnRfZ+=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=JLoQFXYneyI84SfBY3dfC5uPsrz+imumoT0cXdZCSJns0eUfZr+YiMMgdmhSduCXKMsGMcc7Ax/WO2pI+F+J1TOZ/2mpn1lkgx2BuMwoWKxGcDlPnuulxrr2/zrSidd2nKK+q2WL2NJYLHis1m+qCgpqVP7IFxx/JfYVw86NQOE6oXpW1VAJn4/CpN4d3qx79ehAnKN75CT3cGR2HA/IbG4gve4ocwaFFBJIGvw9I9+GdL/i9XDZfj6GbT3P0W9LTZWb9NRI1sQGdf/liaaelITeIewFT9HSeRrDebx5C//j65HsgTjiJujgIldZvLWZPJ1XFxEwtGyZzc4FU3t8LQ== X-YMail-OSG: hAH2RcYVM1lv.zhgVWX10YUIQ3wz0EmpuHCKMT4.hVfNmx9I76pTl0EgZAYq4Fh QNd2woaL5csLGS.d5hAB9BBHniLq_34Ig.rvtABE9zT.PKBgWSjK9w1HS8msZcWXIIDE7LNfSx3h 6IkzOPJUUhcqwGPLTnnKDT4T5fL7aEQVkM6X05pLzfmLCqg5XzFgW0opR.PXaK85I2Ma7JttQb1e 1DnZSis2m8IaHj08NAy4C4Z31p1pUEM961ok0uAVj3H0giTJN_7RFMSYaeWEl6pMlXuXBitwGsgt 6ZsT3ICezm3bnA4VAetUc7QwQqK6OcYLJ8i51RzV4nI5TO1hlXsYyZGZY43vyS39pE8yOcndmp4F 0CpRSs_wz8MM.uyQoyRuXcroJySMjae5HE6Kll29JCwfVU_OGyUCol8Z.fvqX465bKXhClqAon.P P7nhku6a5_8u303XG4mo.CwCGPWZoMFXdoJFupk.adXJxgPl8Wz59LkMFPlPuNW.lazWRkiJhLGW 0UrQ9obDx4lsa2BJdL9PRM5cJtVK9ZLu6DOZiTdJEXzyg9x3CvVT0mRQt8ueK5KwgBlUvJtUiumw sQ22KLKh6uGhgiN.fRXDQs5462eIWNedYeQPGhnfNKHXLq1VrA8qJ2yRf_q4iq7X7u8W71qn6XRP 0c.ROinsL43w8ni_fjbBPe8vMa3WA5mE7ZvAE4FkaInp2TKpMy0s2sKWKePWyBiCe80f7.ZhQ9j7 w_fEQQ_X4xufW5u6zQpTkga8NqONX.7oZbMLCei8SvsYUUzCR2HIZgWFnOVYwhvaQT3ZR2VHvpNI 0RJUYbsGiB.7OdmkHF8iAntbXCLJwAIFKmAoRVAQRn X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Tue, 22 Mar 2022 15:22:32 +0000 Original-Received: by kubenode514.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a39a446f6b5970d8f01de11775f87e36; Tue, 22 Mar 2022 15:22:30 +0000 (UTC) Content-Disposition: inline In-Reply-To: <831qyuf3e0.fsf@gnu.org> X-Mailer: WebService/1.1.19894 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Received-SPF: pass client-ip=74.6.135.124; envelope-from=spacibba@aol.com; helo=sonic310-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=unavailable 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:287357 Archived-At: On Tue, Mar 22, 2022 at 04:49:59PM +0200, Eli Zaretskii wrote: >> Date: Tue, 22 Mar 2022 15:18:15 +0100 >> From: Ergus >> Cc: Juri Linkov , larsi@gnus.org, emacs-devel@gnu.org >> >> > +@code{t} the completions are hidden when some unique completion is >> > +executed. >> > >> >What do you mean by "unique completion is executed"? Both the >> >"unique" and the "executed" parts need clarification. >> > >> unique means that, there is a single candidate o prefix so the >> "added" some letter. example: compi -> compil >> >> The first tab shows completions but the second hides it... it is a bit >> confusing compared to any other completion engine (bash, zsh, >> fish)... that's why I started this changes... > >So we could simply say > > when Emacs is able to complete some characters > >is that right? > I think so, >> > If @code{completion-auto-help} is set to @code{always}, the >> > +completion commands are always shown after a completion attempt, or >> > >> >"Commands"? didn't you mean "candidates" or "alternatives"? (The same >> >problem exists in the doc string of this variable, btw.) >> > >> Maybe candidates is better, > >If it's just "better", then please explain what you mean by >"commands". The text I quoted above says "the completion commands are >always shown". What are those "commands" that are shown after a >completion attempt? > We are just in violent agreement here I thing.. I am saying that as you suggested "candidates" is a better word, more precise. >> > If the value is @code{visible}, Emacs displays completion the >> > completion alternatives when it is unable to complete for the first >> > time; thereafter the completion list buffer remains visible and is >> > updated as you type. >> > >> >Is this accurate and correct? >> > >> "and is updated as you type." >> >> I am not sure that last part is accurate. updates need to update >> in all cases. "as you type" suggests more an icomplete-like behavior I >> thinks. > >Ok, so "the completion list buffer remains visible for all the >subsequent completion attempts". Better? > yes, >> > +current completion candidate will be highlighted with that face. The >> > +default value is @code{completions-highlight}. When the value is >> > +@code{nil}, no highlighting is performed. This feature sets the text >> > +property @code{cursor-face}. >> > >> >This should explain what is "the current completion candidate". It >> >isn't trivial: trying the current defaults with completion commands, I >> >sometimes see a candidate highlighted, and sometimes don't. I >> >couldn't figure out why. >> > >> >> when it is not highlighting? So far the only way to not have a candidate >> highlighted is when there is not candidate effectively selected (like >> when completions are just updated (with no completion-auto-select) and >> the cursor is before the help line; I that case there is not "current >> candidate"); a return in that moment won't execute anything because >> there is nothing to select, so "current completion candidate" means >> that... Maybe you have a better way to explain it? > >Wouldn't it make sense to move point to the first candidate, so that >some candidate is always highlighted? > That may change the current behavior in a more intrusive way and I didn't want to affect current behavior. What you suggest is something I already considered: completion-auto-select t makes 3 things I think should have been spitted into 2: 1) it selects *Completions* 2) Select completions window 3) Go to the first candidate. These options may be probably independent because the user may want to: 1) show completion and highlight (or put cursor) in the first candidate but without selecting the *Completions* Window 2) Select completions window without putting cursor in the first candidate. I thought on this because in zsh the usual approach for this is: First tab: attempts to complete common and shows completions Second tab: go to completions and select first candidate. Following tabs: move to next candidate Right now the combination to get this behavior is not possible, but at least we are closer than before and we give a more familiar interaction with more options... >Btw, when a candidate is highlighted, it is always the first one in >the list, which kinda makes me wonder why this highlighting is useful, >if it always shows the candidate in a fixed location on display? > I don't understand what you mean... The highlight is just the same that used to happen before when the point selected a candidate, then arrow navigation selects a candidate... We just added a more visible hint; not just the pointer... >> Please if you have the time change it... Otherwise I will do in some >> days. > >Will do.