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 13:25:08 -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> <861qcpu0ft.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="37241"; 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 19:40:41 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 1r3hI9-0009Uw-A6 for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Nov 2023 19:40:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r3hHM-0001N5-K8; Thu, 16 Nov 2023 13:39:52 -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 1r3h3C-0001KE-P5 for emacs-devel@gnu.org; Thu, 16 Nov 2023 13:25:20 -0500 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r3h37-0008CW-L9 for emacs-devel@gnu.org; Thu, 16 Nov 2023 13:25:14 -0500 In-Reply-To: <861qcpu0ft.fsf@mail.linkov.net> (Juri Linkov's message of "Thu, 16 Nov 2023 19:28:54 +0200") Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@janestreet.com; helo=mxout5.mail.janestreet.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 16 Nov 2023 13:39:52 -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:312825 Archived-At: Juri Linkov writes: >> 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. > > In fact, the whitespace in-between candidates is the only place where > point could be moved to deselect the candidate. Because there is no space > at the end of the completions buffer, and even at the beginning when > both completion-show-help and completions-header-format are nil. Oh, great! So then let's just do that. Possibly we should ensure there is one character worth of whitespace at the end of the completions buffer, so we can consistently just move point to right after the selected candidate to deselect it. Also... doesn't this mean that with (setq completion-show-help nil completions-header-format nil) *Completions* will start out with the point on the first completion candidate? So M-RET will select it, and with minibuffer-visible-completions=t, even RET will select it? Maybe point should uniformly start at the end of *Completions* instead of at the start? In the one character worth of whitespace we might add?