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:46:37 +0100 Message-ID: <20220322154637.i3hqnxhffme3uuiu@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="28508"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 22 16:51:09 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 1nWgmq-0007FG-IP for ged-emacs-devel@m.gmane-mx.org; Tue, 22 Mar 2022 16:51:08 +0100 Original-Received: from localhost ([::1]:47860 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nWgmp-0000nq-C0 for ged-emacs-devel@m.gmane-mx.org; Tue, 22 Mar 2022 11:51:07 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40808) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nWgjH-0006j0-Fn for emacs-devel@gnu.org; Tue, 22 Mar 2022 11:47:27 -0400 Original-Received: from sonic313-13.consmr.mail.bf2.yahoo.com ([74.6.133.123]:36317) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nWgjE-0006RY-L2 for emacs-devel@gnu.org; Tue, 22 Mar 2022 11:47:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1647964042; bh=6Ek2zwctRbL0Sxcbrx4EW6MMi1aXOlWursK/HeXA7JI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=LqhmChi40zXjDDIBz74M+pvqKV8asFxmlJnb904DgjV8eW0TMYDvznO9YEtmJrhWQxXXG5RJLDNQCRGMU0bB0D01uMFZZjs1TivkCNRpvRh7w0QgOswEtOHDeVLvnatQDyQr2wP/9X5Ytta4rYQYnJ73/6hbueQnKncHdS4sO8emp+7d9dj0v0gMm3XGX5SA98xhsNqTi62WJ68W1X7yo9YmW6ZJ39Bddb1NvuCe+avQ/YIUPPOQJMvpm4+HJlzHO1i2dMp3Eb+BKJi609iB3ykskbzHLyR6h/CeQj2whtMIfBzfP9gbHMKBYSS4SdSIFTXWRgyI2qIsIa2SJpFKJA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1647964042; bh=A7hXiiftM4FbmytgYABTBQqIAHAty8u+vCH4gS4ivpl=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=YlFv2jy1IPjLu+2jquI5+zmajGQsEAjBXi4nDAMA2Dvk2XMkYNwgZLG8lqd26ns0aXzS6naX1uEnvAqczEWqOjfpZe4l/32qWZjRge7sHKInAhxtNxqwvyDE/NdozcRK4ne+YRmXNY5HojaChwV9vK7jVntf4fnnZbx3qg7FnGI/29evo5VegNWnYvwTRktl8PXiB63+DXFWSLT2MCoBZSD/qMNLYeMdepSwv5s6UeJUp11b167aUxjkFhpSrChbDLNPWU6ryAycZ17H4lozmZK/fCgi0wJ6QbTEAM57wzxuX/v7nNym/jqYKOrVfjS6A0o+4ReG9b4WbusqYf2a9Q== X-YMail-OSG: yuN2QrQVM1kBJkZ3hBPA3ow4C1T0TMZh5s7OlIhtnRk8P6T_0C3U.._ljj8GARp OkXZDv.J9.xaxOh1i7ObQ_XHDvkMjMPcgxifu8AYYSSWIZ2JrDUKmc0YVQSBM0J.KAA0u2qtQzPU qI4RTHHXRSO8FqxVpf.Y7exk8u5PSfH1aLYpnPNTyVK16GHzEzSvGS4FoUTkPqACyTKvnhV9voFP pKkbjlwoJAvA9dqLbv12_fmPMfhEGHhFOP7YCHqAeCoImdxRuDcvJOIzEzOVP7IiO2DMso9P4nJF qJnngelxG8IpZXuC_Ww8DRsY71dZFBmY6ZmjlG93nLKRJuFHLN9FlM6Lrh9ydFdu3BdOYlXQVoov yaWzbsaGpLIGGA6CG30VeaHxpVj3o.pl4w_ZojyJspmtsRqkXlJMwpR55zA1HEz_tWWjIe7q68Z5 lwsGgPVXz2BLNs66yPAFkSW4PaKdE6mt8X_ulyp1jxF_D5oIPCLFgtK.lAKlrv4Yf6WjAaPmQooD ThGuW03A79GcttjhK5JyNfeaTQ5diFBs5qBE0rCHjp599Fav56Wm4JXYejiqn8zioT5Sw9oKxXh5 tgrbgwACI4uALUH4XsvwJ40_NCyXLOzUZL6kTIlOKBCxcWiIsnZBz8RGckrg.Uj._UcYva_DrFM6 VjZWctA0A1ObRVbJBgoUscDQN3Qv7qLQoR6GKDjNdjtAQkSW_WWVEk0_iW0ob3L3YR0SRW3cziMt 8avTZU2PPZlV6lPeEszvjM5JO7VFKlYRYF52.evRyIuPxEY5q9eSkxKTE2xP.xOCLy0G3k_dgzhF Q0h_rFlttkH32ypwIJbRKLqu5kGFY3hY5x5l5NWFX6 X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Tue, 22 Mar 2022 15:47:22 +0000 Original-Received: by kubenode516.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b5197e1a73d7fde266762773de020374; Tue, 22 Mar 2022 15:47:16 +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.133.123; envelope-from=spacibba@aol.com; helo=sonic313-13.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:287358 Archived-At: BTW Eli: Some of the new and old completions customs have some name miss-matches: some of them are called completion-something and some others are completions-something in plural. There are some of them with `:group 'completion` while others don't have that... could you please check if the names could be standardized and may be added to the right group?? Specially the options I added I am not sure if they are well named and for sure they don't have a group name... 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? > >> > 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? > >> > 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? > >> > +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? > >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? > >> Please if you have the time change it... Otherwise I will do in some >> days. > >Will do. >