From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.devel Subject: Re: Navigating completions from minibuffer Date: Wed, 15 Nov 2023 17:03:49 -0500 Message-ID: References: <25929.50004.710119.599023@google.com> <868r7af3v6.fsf@mail.linkov.net> <25930.31126.454503.607723@google.com> <868r78bsnx.fsf@mail.linkov.net> <87y1f569c0.fsf@catern.com> <86fs1c3yml.fsf@mail.linkov.net> <864jhokelp.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5973"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:hKvpJpC8s/rKJ2Z3rh9+xtolGKk= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 16 06:34:53 2023 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 1r3V1h-0001EE-SD for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Nov 2023 06:34:53 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r3V0l-00005S-PA; Thu, 16 Nov 2023 00:33:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r3NzS-0004N8-1V for emacs-devel@gnu.org; Wed, 15 Nov 2023 17:04:09 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r3NzM-0005at-37 for emacs-devel@gnu.org; Wed, 15 Nov 2023 17:04:02 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1r3NzJ-0004oU-3u for emacs-devel@gnu.org; Wed, 15 Nov 2023 23:03:57 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 16 Nov 2023 00:33:54 -0500 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:312782 Archived-At: Juri Linkov writes: >>>> Probably we have to make RET more smart, so that when more editing >>>> was performed in the minibuffer after the completions were displayed, >>>> then to use the minibuffer contents with exit-minibuffer, >>>> not an obsolete completion candidate that remains selected. >>> >>> Interesting solution! So if the last relevant command was changing the >>> selected candidate, then RET submits the candidate; if the last relevant >>> command was editing the minibuffer, then RET submits the minibuffer >>> text. >>> >>> What about the case where I type some text, switch between some >>> completion candidates in *Completions*, then decide I don't want any of >>> them and hit RET to submit the minibuffer text? That's something that >>> works today. Can we support that somehow? >> >> Currently the suggested way to avoid selecting a highlighted candidate >> is to close the completions window with C-g, i.e. it adheres >> to the principle “what you see is what you get” - when you see >> a highlighted candidate then you will get it, otherwise you will get >> the minibuffer contents. > > So there are at least 2 variants what to do when completing-read is used > as selection rather than completion: > > 1. On editing the minibuffer close the completions window as expired. This would make it difficult to narrow the completions by typing in some text from them, though. I think I relatively often: 1. TAB 2. Look at *Completions* 3. Type in some text from one of them Step 3 would harder if *Completions* disappeared on the first character I typed. Perhaps instead typing a character could deselect the currently selected completion, rather than hide *Completions*? But it seems nice to maintain the selected completion as you type, as a visual guide, and also my other patch maintains the selected completion between each TAB, which is nice. Maybe... we could somehow de-activate the selected completion, visually de-emphasizing it in some way, but still showing its position in some less-significant way? An underline, perhaps? And subsequent operations which change the selected completion would reactivate it, making it the selected completion again. That might be a bit tricky to represent visually in an intuitive way, but it might give us everything we want. Maybe we could represent that visually by moving the selected completion indicator (which in emacs -q is a green highlight) to *the minibuffer* when the "selected" completion is not actually active. Then the user would quite quickly get the idea: RET submits whatever is highlighted in green.