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: Thu, 16 Nov 2023 09:41:24 -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> <86il62tbfa.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9422"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 16 15:59:52 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 1r3dqR-0002Bo-5y for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Nov 2023 15:59:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r3dpd-0000J8-1L; Thu, 16 Nov 2023 09:59:01 -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 1r3dYg-00016p-7p for emacs-devel@gnu.org; Thu, 16 Nov 2023 09:41:30 -0500 Original-Received: from mxout1.mail.janestreet.com ([38.105.200.78]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r3dYb-00028k-74 for emacs-devel@gnu.org; Thu, 16 Nov 2023 09:41:30 -0500 In-Reply-To: <86il62tbfa.fsf@mail.linkov.net> (Juri Linkov's message of "Thu, 16 Nov 2023 09:16:57 +0200") Received-SPF: pass client-ip=38.105.200.78; envelope-from=sbaugh@janestreet.com; helo=mxout1.mail.janestreet.com 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, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 16 Nov 2023 09:59:00 -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:312800 Archived-At: Juri Linkov writes: >>> 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. > > In case of completion-auto-update=t the selected completion should be > maintained as you type indeed. But when completion-auto-update=nil > instead of forcing the completions window to be closed it looks better > just to deselect the current completion. Yes, agreed on that point. When completion-auto-update=nil, It is better to deselect the current completion than close the completions window. >> 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. > > Usually the active editing area is not highlighted in any way. > So better would be to use highlighting only in the completions window. Yes, but I wonder if we could have some simple indicator in the minibuffer which isn't too visually noisy. And which is only activated if the user has previously selected a candidate in *Completions* and then deselected it by typing. Maybe highlighting the minibuffer prompt instead of the text? Well, not really necessary, just a thought. > For completions-highlight-face=t it's clear that deselection should > remove this face. But what to do for completions-highlight-face=nil > is not clear. Maybe just to move point to area with no candidates? I had been assuming "move point to area with no candidates" was how we would implement deselection in any case. Since "point is on a candidate" is the definition of selection, as it stands. Maybe we can deselect by moving point to just before (or after) the selected candidate? Move point to the whitespace in-between candidates. Then no candidate is selected, and completions-highlight-face won't highlight any candidate, but there's still a bit of visual indicator (window-point) which shows what candidate was previously selected, and if the user does want to re-select the candidate, the user can just hit (or ) to select the candidate again. And completion-auto-update could maintain this state, too, just like it maintains the selected candidate: if point is right before (but not on) a candidate, it should stay right before (but not on) that candidate as the user types and *Completions* updates.