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: Navigating completions from minibuffer Date: Thu, 16 Nov 2023 09:16:57 +0200 Organization: LINKOV.NET Message-ID: <86il62tbfa.fsf@mail.linkov.net> 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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14771"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) Cc: emacs-devel@gnu.org To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 16 08:25:20 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 1r3Wka-0003kc-Bs for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Nov 2023 08:25:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r3Wjl-0003R1-Lb; Thu, 16 Nov 2023 02:24:29 -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 1r3Wjf-0003Qm-SV for emacs-devel@gnu.org; Thu, 16 Nov 2023 02:24:23 -0500 Original-Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r3Wjc-0002JW-4t for emacs-devel@gnu.org; Thu, 16 Nov 2023 02:24:23 -0500 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 7E39160003; Thu, 16 Nov 2023 07:24:16 +0000 (UTC) In-Reply-To: (Spencer Baugh's message of "Wed, 15 Nov 2023 17:03:49 -0500") X-GND-Sasl: juri@linkov.net Received-SPF: pass client-ip=217.70.183.195; envelope-from=juri@linkov.net; helo=relay3-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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:312785 Archived-At: >> 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. > 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. 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?