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 15:21:08 +0200 Message-ID: <20220406132108.evlofp5l3krsl5h7@Ergus> References: <20220401153839.idrzrbfl2yfzga3y.ref@Ergus> <20220401153839.idrzrbfl2yfzga3y@Ergus> <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> 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="13824"; 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 15:22:10 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 1nc5bu-0003Lz-LE for ged-emacs-devel@m.gmane-mx.org; Wed, 06 Apr 2022 15:22:10 +0200 Original-Received: from localhost ([::1]:43640 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nc5bt-0004RN-1n for ged-emacs-devel@m.gmane-mx.org; Wed, 06 Apr 2022 09:22:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44914) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nc5b9-0003lL-5H for emacs-devel@gnu.org; Wed, 06 Apr 2022 09:21:23 -0400 Original-Received: from sonic302-2.consmr.mail.bf2.yahoo.com ([74.6.135.41]:44513) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nc5b5-0004NZ-Vk for emacs-devel@gnu.org; Wed, 06 Apr 2022 09:21:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1649251278; bh=kzyRzJIBnvc4N3cC17Qb7qIA+goxuGuf7xJTmjHBljI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=RcypuIW6xYQZ9ZWVDl2hXobzK8Lw3qUxdjm26qPhgdfC4RIh7KGeqTo/tB3AnldiRq7Y1/4QH48TKAYZpEoo0w6kxys6EIuDhmTk22dCklIJmW+FdLjaHTUTM4ke9IZweaSv3nqyBVotFIEyIeXTAY1ezzLgliwLVepT96S0reShwKeuaSMsuSWhP+5sZmu2kyo0ydmi9kf+9DsNgm//NCcLhPXBPqHvxnx6R4QQXPgcod7yhavFP4oW3XzEtWLwScq1+qzL3BNG3OBzrgsj8N1wiKSK6wwQ/wKRrI1p6SPieVrHNwxeEF5sxKV7otQiKJ77cJFGrf+cJf7YZoqSdA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649251278; bh=mG28kpu6v6Gfk+I9mTlIzLz8ewdmKZn3xT659JFyDqd=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=iU8ac0OGgIqk29jVVEdInJXbcButfN10G4XdZvSwVqOrtmHNplPUzF+PeA1prXXcQ0dKYREDqkutTyAEqWMIM+MEuCARx+zeVts7BMkpBygAjt5DppooCrr8UvXHhJcwj18kwcZtEr5eWSG169ZqWLdJMUY2JPzuiLCAh1PJ3kLX99TbvEDd8njBrCfmpIRLNohCggrHuOx2Ed3zc8vNgSlDowukfLMQG4hzJB51HuOcPbZFm5/oaEyIeONPeWNU/x3lbGDKAgBQoLMpl3YmEQZS0LpJL3kcxyglp1gW6SlejHbvqURlAaUiLXeb2fmyvCIP8VkFnIop/M/ggdgoAQ== X-YMail-OSG: fMoW5pQVM1k6XnKuFkj4r7o8FikeQpLOIHZsaVNhggyxxa6bRzMOFL3ksSc6klx mKYIwTszgnPJNksl6U5kXm4nFoDL0z2EyutVPDxbyAXQO3NpbGw81F5QR7_bl81jnMfq_mKZwwJO wraXcmkwXDRmEqiSmwB7pSr5vomjo4in.YYqhlsvnwnHj34f5A84rxmC5RQET3Lg62dEdwYc_RJv 7tw05WsHStWE.NJBCQZDyD0.yO0loLZmLMKZMrGxQvhdhz37yMI9EPBSYbRGFsNrIAKHJy5_frWE kEVC8OYfMF5iqMI.afHHjxi2JKBwI9G4uHbGZHYc1FcTzq_xmYyqnBESZNW0cNp5l5nzaMTitdRY _vpJm8hlXMZizjtHXjt023ubExGf_PJsNS0.HCsMijlEokR8DVijfOt6_Crli98rRaF7Z65iFroA cBuKS9VEZkfGYi.traEmrO3P6.c12p4mmhI9sqUw_3SW9n1StZ6U7Z3bjo6zbEmId7cEBnSeWZ5g AuEDJwi.9UqLx9ouEVK6mx34HTgstRAtjsl24Z7Y2Oc8VmQSHTBeYdP_3_5Qzzl6Wa2L9d5Ur18y x.wyDITCrdfyw8g_Vklz7DHJp4HWDGA58kPkkAgQXqmtZnWv01RTwucY5X1TvPQdaZht8MyGToCp acBypHycGgOOarYvwgWUKt85BSYTCC.FjN_l0YkZRoqNy1NgwUzjCw84PYlqzKqjHfgU0wa3ychQ Rog_GHhZbjzmKFCSDQr_I3lOeZ3Gwt_Ehj1wZfhVXaMkbJMGz5q_xjQQQS0vqMv_jaXsRCOcqlF4 mxOvWASY3t8_nNLiAa3BvjFlUzGXxwqXgPccZcX5fd X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Wed, 6 Apr 2022 13:21:18 +0000 Original-Received: by hermes--canary-production-bf1-665cdb9985-tmblj (VZM Hermes SMTP Server) with ESMTPA ID 72985c136b517167d985bba75f48ed18; Wed, 06 Apr 2022 13:21:14 +0000 (UTC) Content-Disposition: inline In-Reply-To: <86a6cyiqlt.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.41; envelope-from=spacibba@aol.com; helo=sonic302-2.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:287839 Archived-At: On Wed, Apr 06, 2022 at 10:35:36AM +0300, Juri Linkov wrote: >> Thanks for this... Sadly after trying it for a while I find it very >> uncomfortable. :( maybe we can do something to improve it please?? > >This is not surprising. This explains why we still had no such feature >for a long time. It's because there are too many different expectations >how it should work. But maybe it would be possible to find a set of >customizable options that will cover most use cases. As least we could try. > >> 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. >> Alternatively (IMHO much better one): >> >> Maybe you could consider to insert the candidate, but keep the cursor in >> the same place and add a shadowed suffix after the cursor in the >> minibuffer. So M- navigates, and inserts suffix but if the user >> types a letter the suffix disappears and the letter is inserted in the >> right place. In contrast if the user press RET, as the candidate is >> already inserted the current behavior is unchanged. > >Isn't this behavior too confusing? When the suffix is shadowed, >do you think the user will have the clear idea what will happen >after typing RET? I took the idea basically from some configs around for fish and zsh.. >How will it indicate that typing >a self-inserting character will delete the suffix? That's just an option. We could also enable a C-g like in default zsh: som -> some some -> Completion list with: `someone, something, sometime`. There is a custom to auto-select the first candidate inmediately or require a second tab... (similar to our completion auto-select values...) Whenever a candidate is selected, the prompt is completed (similar to your code as now) but the list can be explored with the normal arrows while it is visible. The main difference is that the user may cancel at any time with C-g, so the candidates list is automatically hidden BUT the prompt goes back to `some` (not cleared as now); so the user can continue typing and again. If the user inserts a letter at any moment with the completion list visible and a candidate selected, then the candidate is keep and the letter inserted after a space. `someo` will produce `someone o` `someo will produce `someo` In any case you will see the full `someone` after the and the whole list, so RET will finish the completion and a second RET will use it... We can simplify part of this behavior because the emacs minibuffer does not use multicommands or multientries on a command like: command arg1 arg2 and so on... So RET could maybe complete and use as now... But OTOH I will strongly recommend the C-g and arrow navigation behavior... That could be maybe implemented with a set-transient-map... > Maybe better to activate the region over the suffix? >Then it will follow rules of delete-selection where >a self-inserting character is expected to remove the suffix region. > >> 2) The M-/M- is not intuitive when completions are not in >> one-column format, > >M-/M- could be rebound to call next-line in the >completions buffer. > >> and the M-/M- cannot be used because >> they are already taken.. Do we have any other alternative? > >Indeed, horizontal navigation is a problem since M-/M- >can't be used by default, only after enabling a new option. > set-transient-map?? >> I think there is a problem any way because 2d navigation with this >> is impossible... > >Why 2d navigation is impossible? It's possible in the completions >buffer where is next-completion, and is next-line. > Yes, but from minibuffer it will collide with one way or the other right? >> 3) I think that the bindings in the minibuffer must be enabled in the >> completions buffer as well, otherwise it becomes unconfortable; >> specially with completion-auto-select. > >Agreed, M-/M- can be bound in the completions buffer. >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. >>>I noticed that your patch broke some corner cases: >>>when using minibuffer completion navigation commands, >>>it fails to go to the previous completion at the top. >>>But since this is now in master, you can see it yourself. >> >> My patch can only affect the TAB and backtab commands (look at the if >> condition)... So I don't see how it could affect you commands ;(... I >> will give it a look tomorrow... > >Sorry, now I can't reproduce the previous problem, it seems to work fine, >except the problem reported in bug#54374. Best, Ergus