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: Sun, 19 Nov 2023 09:08:36 +0200 Organization: LINKOV.NET Message-ID: <86sf52tf0b.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> <86il62tbfa.fsf@mail.linkov.net> <861qcpu0ft.fsf@mail.linkov.net> <861qcorh4c.fsf@mail.linkov.net> <87jzqen5h0.fsf@catern.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2002"; 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: sbaugh@catern.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 19 08:11:23 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 1r4bxi-0000Ni-U0 for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Nov 2023 08:11:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r4bx5-0000sb-S8; Sun, 19 Nov 2023 02:10:43 -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 1r4bx0-0000rm-7o for emacs-devel@gnu.org; Sun, 19 Nov 2023 02:10:40 -0500 Original-Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r4bwx-0007UL-V6 for emacs-devel@gnu.org; Sun, 19 Nov 2023 02:10:37 -0500 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id BB268C0005; Sun, 19 Nov 2023 07:10:26 +0000 (UTC) In-Reply-To: <87jzqen5h0.fsf@catern.com> (sbaugh@catern.com's message of "Sat, 18 Nov 2023 20:58:51 +0000") X-GND-Sasl: juri@linkov.net Received-SPF: pass client-ip=217.70.183.198; envelope-from=juri@linkov.net; helo=relay6-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_H5=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:312951 Archived-At: > OK, how about this? It's an adapted version of my > completions-auto-update patch, which provides (for now) only the feature > of deselecting the completion when point moves or the minibuffer > changes. The infrastructure for doing this turns out to be basically > identical, which is interesting. Indeed, it's easier to start with a simpler case, and then gradually to add handling of more cases to the same option. > It sets completions-auto-update to 'deselect by default, which I think > is reasonable? Isn't deselection needed only when minibuffer-visible-completions is enabled? > minibuffer-visible-completions makes RET submit the selected > completion candidate, if any, ignoring the contents of the minibuffer. > But a user might select a completion candidate and then want to type > something else in the minibuffer and submit what they typed. > > * lisp/minibuffer.el (completion--insert): Add a space before each > candidate. I don't think anyone would like such a space shifting the whole layout to the right. Rather I'd recommend to use a space after each candidate. There is already a space between candidates. Only at the end a space is missing. Or without adding a space at the end we could change `choose-completion` to not select the candidate when point is at the end (`choose-completion` needs fixing anyway since currently it raises an error at the end of the first completion in case of no header.) This still won't solve the case of no header. So in this case for the initial position we could add a narrow line at the top: (propertize "\n" 'face '(:height 0)) This solves a lot of problems, and will help to remove the complicated special-handling of the 'first-completion' text property in many places.