From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Re: Other details about completion. Date: Wed, 06 Apr 2022 10:35:36 +0300 Organization: LINKOV.NET Message-ID: <86a6cyiqlt.fsf@mail.linkov.net> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23699"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) Cc: Philip Kaludercic , emacs-devel@gnu.org To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 06 10:19:26 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 1nc0sw-000631-2k for ged-emacs-devel@m.gmane-mx.org; Wed, 06 Apr 2022 10:19:26 +0200 Original-Received: from localhost ([::1]:44394 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nc0sv-0002m3-3X for ged-emacs-devel@m.gmane-mx.org; Wed, 06 Apr 2022 04:19:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48920) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nc0j3-0000wp-2L for emacs-devel@gnu.org; Wed, 06 Apr 2022 04:09:13 -0400 Original-Received: from relay5-d.mail.gandi.net ([2001:4b98:dc4:8::225]:41325) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nc0j0-0005et-6e for emacs-devel@gnu.org; Wed, 06 Apr 2022 04:09:12 -0400 Original-Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id CE4D21C000A; Wed, 6 Apr 2022 08:09:03 +0000 (UTC) In-Reply-To: <20220405232013.5y5jnr4ykzqgxqla@Ergus> (Ergus's message of "Wed, 6 Apr 2022 01:20:13 +0200") Received-SPF: pass client-ip=2001:4b98:dc4:8::225; envelope-from=juri@linkov.net; helo=relay5-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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:287828 Archived-At: > 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. Whereas more hard to type M-S-/M-RET as a rarely used alternative. > 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? How will it indicate that typing a self-inserting character will delete the suffix? 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. > 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. > 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? >>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.