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: [PATCH] Re: Other details about completion. Date: Wed, 6 Apr 2022 19:45:32 +0200 Message-ID: <20220406174532.chsgqkzd2gphyuh3@Ergus> References: <86r16g92v5.fsf@mail.linkov.net> <20220401202425.jfrwqmkm3ffmcm5h@Ergus> <20220404193501.adojhz7uvvaoq4sj@Ergus> <86czhw4oqr.fsf@mail.linkov.net> <4E8D9AEF-4D7A-4B11-822F-8D0911964A05@aol.com> <86bkxfibdo.fsf@mail.linkov.net> <20220405232013.5y5jnr4ykzqgxqla@Ergus> <86a6cyiqlt.fsf@mail.linkov.net> <20220406132108.evlofp5l3krsl5h7@Ergus> <86sfqqduon.fsf@mail.linkov.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="37971"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Philip Kaludercic , emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 06 19:52:28 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 1nc9pT-0009fC-Ta for ged-emacs-devel@m.gmane-mx.org; Wed, 06 Apr 2022 19:52:28 +0200 Original-Received: from localhost ([::1]:50704 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nc9pS-0002nK-Sp for ged-emacs-devel@m.gmane-mx.org; Wed, 06 Apr 2022 13:52:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60272) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nc9iy-0002Wf-1q for emacs-devel@gnu.org; Wed, 06 Apr 2022 13:45:44 -0400 Original-Received: from sonic310-14.consmr.mail.bf2.yahoo.com ([74.6.135.124]:41728) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nc9iu-0005SC-C3 for emacs-devel@gnu.org; Wed, 06 Apr 2022 13:45:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1649267138; bh=nY0uCPIEGPeCo+DTYiujfwYwQO/uPSfMViAUgPe0XNk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=XiNFnQ4I3qyxiCGTr47+zVjQ1wKC9gbmEyV3bQ3w1TbQ0TwM3skv8FWRfVwUgGTSwkWsMtWlbAXPDFGxA2M3K94Bt8MW6cfJSlhp+iAw5pySS911QIBspM2atp+6uey2SiGcLHG/0ucOLulh/z5Y3eOroYxUc6m/KTlaMu9hspgS6V7oZWR2uQqXCQxkGrLLhxMbTd9Pxa0zPylD4gp7YpVUgN6RtCHhQDZ46KqG72swNZ0R/OJVDfjdwOnMmYUoJdCFZrfNpRBO6YYczsADHmQ8h6NaH38SqvE2y+0aC+E+Z8X4GW0jbyHPGGxt9uENevhPcSw/Na8215Js9ylqKQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649267138; bh=9Nz2kTcOp502b1KQjEK6I6RvjZyBf6Ooya5ZJ+xhOlw=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=uMeIsGBmmdDix5UbW0eZu1oS1tswgr7UjOasMPiEO+8Ywukt72Q2xcNvoSoXLYkPUTO2B4HUZtw8zSQhmLARDnNGjWTYwV7lkFswiPdw/d6eCZqhdgcYy0nw+KT9FbTQlcpTjD5RZ6AkjzqtjgUnRplBsFGQpkpaPDqJStoApTtvLZvjMyaBxbxZlc+5ukgxnBY5Kcb9qGVW+NTt41QzGcblbOj45hTlwYRH4CHVqjBuNSMHqhGjrXOjREZ96Kql4sUEbkFyppJ7iWW3o1tJf+C4ZrzH4rm77PHYyZ0cJ16ycYmBZ/ljqBUYt0wn+yo8HqjACL7zIVzzF69kk5qVlw== X-YMail-OSG: cA4_UAIVM1mV1vIVBGCkRUN1w6GsBtXvxT3lZHnq7qHcrSgv6l5oezATHV7LaeW O9COi.uFxEU.3YNkpZV3Pptkc15qx5XFXtRUJguAx4dT.Xhm9fsjZRiW1vG82Tvpzj8hghubPine zxfsaIPg54cTi8jr.85oLA3BORdRIt2vOtU3zETHw1vePiNYkeWjLcQk.bR6d8tGoGKsTGnfTEqy LqLIe_EXUvKzUIDRdAFNlxYr_fcYcwKhLtWpnd6edsuippPXXCNsMReqmtFZ2OR1ag0GQCBVzUmt pFcUdlviYwMNjvsepqcXrqWW0Rds3JTj321mgO9ipiLuzPGPLlVyujlg61Z.7xEuMFpAjFi9juiz Lc7Tvu3xJ1TQ2Zl5SUEC4F4DJgjzdG4daGUAtcJa1VqnvXZxFRT2K6WrCqr69sc4dmCnGmMxHKMA JSp96z5EB0ggOScOVK3MK0LZxNq59suJLryzEx01JvTb.ta_h1cbEQLtw3egGA8b8sXurWZ9zPer A7Xl4.tr7Zyjw2Gyt7fNUeyi4hsV8xKGy.MIlxidC4RK5F2KrThKyPsozCOQCPwuZkHTfCxidc00 xUHZw73ipOF4sxx39F2MGuY6MJo7P_FhgvShcvA42OzLHehH5ODXYQwQVgNmcEuc_BfgZpwe5CBG EUAn05nUmcFqm6zKRPK0hR4HOYJn_0tfvogRUwmAejd9yxWfDKF1alDy_WSKHthacvFFFw4dYPP8 Gx8gfK5si6ektgqSjzvjFxKHqoLHaVV0_kdli35lBvpIuxFMDvF_B29qXlphxwtDvOwUjat5wni7 T75RF_xIj5gXIhDygfUN58OqbH9Gnt4k_GHqdrXinC X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Wed, 6 Apr 2022 17:45:38 +0000 Original-Received: by kubenode515.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 49f27e190e1d7e245c8d692cab5b9758; Wed, 06 Apr 2022 17:45:37 +0000 (UTC) Content-Disposition: inline In-Reply-To: <86sfqqduon.fsf@mail.linkov.net> X-Mailer: WebService/1.1.20001 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=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:287846 Archived-At: On Wed, Apr 06, 2022 at 07:48:40PM +0300, Juri Linkov wrote: >>>> 1) I think it is more intuitive to invert and use the M-S- >>>> minibuffer-choose-** and M- for >>>> minibuffer-{previous|next}-completion for not insert commands... >>> >>> Easier to type M- were intended as the primary way to use this feature. >> I know, but such primary behavior is too intrusive IMO. >> >>> Whereas more hard to type M-S-/M-RET as a rarely used alternative. >> Mi proposal (the suffix one) is basically to avoid the need of M-RET. > >So your proposal is something in between. Then maybe instead of two sets >of commands (that either insert the current completion or not) we could have >one set of commands bound to M-/M-, and a customizable option with >three values: insert, don't insert, use transient suffix. > I would prefer something simpler even if we need to sacrifice some functionality or customization... >> I took the idea basically from some configs around for fish and zsh.. >> ... >> But OTOH I will strongly recommend the C-g and arrow navigation >> behavior... That could be maybe implemented with a set-transient-map... > >What is also interesting to note is that even every web browser >uses own completion logic: > >1. in Firefox: the suffix of the first completion is inserted to the > address bar as the selected region, but / inserts > the completion without selecting its suffix, like M-/M- > currently does in Emacs. One ESC closes the completions window, > another ESC clears the address bar. > >2. in Chromium: / inserts the completion without any selection, > like M-/M- currently does in Emacs. One ESC clears the > inserted string, another ESC closes the completions window and clears > the address bar. > Yes but there are three key differences there: 1) browsers show the completion list immediately (like icomplete and it's family), so they don't require a tab to show the completion list or any binding to jump to/exit the completions list either. 2) the browser completions are shown vertically only, so no horizontal navigation is needed and not modifiers to the keys are needed either as there is not any collision of bindings. With the plus that the user can go to the initial prompt (without completions) just by moving to the first candidate (up arrow)... so no applicable to us either. 3) The search they perform is on the history, so when the candidate is unique it is inserted and selected, so easier to erase the suffix if needed with backspace or insert at the end (right arrow). In either case 1) there is not a two step to insert+execute 2) there are not special bindings 3) There is an intuitive way to keep the completions like it started (remove the suffix) either hiding or keeping the completion window. Maybe we must look more at the fish/zsh behaviors than browsers, because browsers are too far from our infrastructure... BTW: do we have any sort of history search based on the inserted text like bash history-search-backward?? >>> But what about M-/M- for not one-column format? >> >> This just confirms me that the initial approach implemented with a minor >> mode (or using a set-transient-map) may be a solution. > >We started with non-intrusive keybindings. But indeed, more intrusive keys >should be enabled only depending on a new customizable option. > >Here is the next patch that does this and allows using all arrow keys >only when the completions window is visible: > I will try this and comment, thanks!! Best