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 15:18:15 +0100 Message-ID: <20220322141815.2iq7jec2d5lvfox3@Ergus> References: <86k0d06dik.fsf@mail.linkov.net> <87ee3714li.fsf@gnus.org> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19134"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Juri Linkov , 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 15:21:16 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 1nWfNr-0004iX-4F for ged-emacs-devel@m.gmane-mx.org; Tue, 22 Mar 2022 15:21:15 +0100 Original-Received: from localhost ([::1]:57460 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nWfNq-0000uH-4n for ged-emacs-devel@m.gmane-mx.org; Tue, 22 Mar 2022 10:21:14 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44178) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nWfLq-0007CN-0A for emacs-devel@gnu.org; Tue, 22 Mar 2022 10:19:10 -0400 Original-Received: from sonic309-13.consmr.mail.bf2.yahoo.com ([74.6.129.123]:43736) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nWfLk-0005rt-UU for emacs-devel@gnu.org; Tue, 22 Mar 2022 10:19:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1647958741; bh=eIU7PAIb+TWQnR6VvOwfgCwXg7DSMEhWIwIpgsFG5mM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=pObWcnnJMR/0nrDsT5z42NO1smu3+N1Ky3JJMMHJE2X52A4v1JShu8Ls6O8pdbu7IZF8T1plfQZHuorlRgMYe8x0mnbm4qsVsgogVYwJTLJ8mpkrpWqMmP903VigqJthI8ubjSQ1C3Qg7D7mKWgv950ZNxUefzItCdAK/el8b4+ioyiymKtCLVrUqGsSDlziySqsbDC74/ziEagwKP7M47+PukFe4WwiUG5G2ErhITd0n/vdc4Z+sLe7br42F4KVdaR/DGu4LYeT5EGqoh54KglUEQvLp4REEUTdVf1X3rgd3jeOljubW/tLJbdZgof2N4GqSCkmfZZLYuKw5P38uw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1647958741; bh=myBnAiZs5AdTxvMy1LIxc5y4s4cBr5F7PoeAillWuKD=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=DzMC3olT5KJyDUZ6SDsLq06ZoCGkMhVzb/NrDowxIFjA0qIM0qoCdGGHPYkAUHUg7X2ntTDXYipvNwVr3mDlICohEwzc9Eo6WU7ltIFS2WmIkGSYe1HPSJT56U7smwfi2t95t7JhECu+X8PwboVaH3tCPmJJkMOhCCSy7xvnLu9Iq1XWASKeTAi92QPRozVIK/QQvmu9mQFEeEuCxVoExOpCQ1z8R6dNgYRbtujO1CM3CcXHMoyhDkWgZwreVqbV8a8+giU0FE4OEU5GWVN5K3EfIe8HgVxFDrXsH6TBHBlLMQ5+DlmHzgzDgOKc8J9kHxiEVOJu5wjd/ggwtkOWSg== X-YMail-OSG: F5pYLzcVM1lYcutC2Oi_oeL6dyNgWmtTEj5.dCl5ZP4kan_wk0QRdJbWn998MAI n7zD7VQ82E6hheudFJHLfuegntPGu1ymOfsKNgc5x0ZRFsfpMTILTwX.4DE_p9jts3vlvmd8Xlh. shp7D5IzS2L..16PKzj7WIzC30vhdqvXRgjI9jdQxM9MVO.ulA5Sv9Y37RYfx89Q5FIOjOvYDTKY ZO4RTc5V7DL09t0_L1zrQv2FNNes34ULnwVaVsg5v.dCrIq161zinuf1scOGC0EQ.rPAF9InJ8A5 72lyQcJDd4kEZG_Sara3V95HAWQtak_quwjftZ2mX6yCtVpcd_LTr1SF9HVGo.m7IbU2yFfNEoar hFa.97.G8ui.DwT4mIBMj1HrywHRJgqZwKE8ll5NPjzA4bhNx5c6WaujMeNqsimjGT4yLea2sxX6 deZHON5dYPYsJNqa51c8C68GLwD3HOPu9SBuCC0jFvzomzK.o0e6B4mWhlfsUUcccCOh7CUKlc0r LTFroQSaBvAsS103DonSxaVEDRtwGNVT9UYxcry10CYmm7QrPuKqyQC.cgEtksh6RVl5_MIGjVrg uou9qZhq56v2MBKa2T1lTCbY95TUWnAp77uu87woxpvSFv8qC28.x4rVHH1q1Z_aRwjXfqzd6uR4 3e.BfkUnouTq_8KLxBOdCtmczg5_I.gTNXu0NJ5yP93ckHY4k8O4L2LHY6mDch54qhZuz5svYpxN N36Om5o7S7xTjcQfJWDZTGOB1ZKZFlXnZNFoq4q4L54eS.kfcIiclvfSXukpWJNn2CDC583fJTkc qD3huLHTOd.zmw4AINcCaQ0PdASuRC.6QUoTBLhdbH X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Tue, 22 Mar 2022 14:19:01 +0000 Original-Received: by kubenode515.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1151af33bd0330d978ff2694e458a82b; Tue, 22 Mar 2022 14:18:55 +0000 (UTC) Content-Disposition: inline In-Reply-To: <837d8mf6pf.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.129.123; envelope-from=spacibba@aol.com; helo=sonic309-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:287355 Archived-At: On Tue, Mar 22, 2022 at 03:38:20PM +0200, Eli Zaretskii wrote: >> From: Juri Linkov >> Date: Tue, 22 Mar 2022 10:24:00 +0200 >> Cc: Ergus , emacs-devel@gnu.org >> >> >> Since Ergus finished implementing new features in the >> >> feature/completions-customs branch (and I fixed small things >> >> like renaming completion-header-format to completions-header-format), >> >> the branch is ready for merging to master now. After that >> >> we could add more patches based on new features. >> > >> > Sounds good to me. >> >> So now the branch is merged to master. Thanks Ergus for implementing >> these features. > >Thanks, but please see some questions/comments below, and either fix >them or explain what you meant so that I could fix them: > Thanks to you > If @code{completion-auto-help} is set to @code{nil}, the completion > commands never display the completion list buffer; you must type > -@kbd{?} to display the list. If the value is @code{lazy}, Emacs only > +@kbd{?} to display the list. If the value is @code{lazy}, Emacs only > shows the completion list buffer on the second attempt to complete. > In other words, if there is nothing to complete, the first @key{TAB} > echoes @samp{Next char not unique}; the second @key{TAB} shows the > -completion list buffer. > +completion list buffer. With the previous values and the default > >What are those "previous values" which you mention here? t, nil, lazy > > +@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... > 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, > +updated if they are already visible. If the value is @code{visible}, > +then completions are not hidden, but updated if they are already > +visible while the current behavior stays the same as default if they > +are not. > >I think the last sentence should be reworded as follows: > > 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. > +@vindex completions-header-format > +The variable @code{completions-header-format} is a formatted string to > +control the informative line shown before the completions list of > +candidates. It may contain a @code{%s} to show the total number of > +completions. When it is @code{nil}, the message is totally suppressed. > +Text properties may be added to change the appearance, some useful > +ones are @code{face} or @code{cursor-intangible} (@pxref{Special > +Properties,,Properties with Special Meanings, elisp, The Emacs Lisp > +Reference Manual}). > >Shouldn't this have a cross-reference to where header-line-format is >described? This variable determines the format of the header-line >shown in the window that displays the *Completions* buffer, right? So >knowing what can be used in header-line-format should be useful. > You are right... I just didn't even know there was a header-line-format ;p > +@vindex completions-highlight-face > +When @code{completions-highlight-face} is a face name, then the > >Saying "face name" might mislead people to think this is a string. It >is better to say "If the value of this variable is a face, ..." > >Also, I'd lose "then": it's redundant here. > > +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? > +@item cursor-face > +@kindex cursor-face @r{(text property)} > +This property is similar to @code{mouse-face}, but the face is used if > +the cursor (instead of mouse) is on or near the character. > ^^^^^^^^^ >Which character? There's no reference to "characters" in the >preceding text, so this is confusing. > The previous text for mouse-face says: ‘mouse-face’ This property is used instead of ‘face’ when the mouse is on or near the character. > I suggest something like > when point is inside text which has this face Maybe: when point is inside text which has cursor-face property Please if you have the time change it... Otherwise I will do in some days.