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: Sun, 19 Nov 2023 14:41:37 +0000 (UTC) Message-ID: <878r6tn6uf.fsf@catern.com> 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> <86sf52tf0b.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24963"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 19 15:42:11 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 1r4izy-0006GF-Q8 for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Nov 2023 15:42:11 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r4izX-0004WL-3L; Sun, 19 Nov 2023 09:41: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 1r4izV-0004Vz-C4 for emacs-devel@gnu.org; Sun, 19 Nov 2023 09:41:41 -0500 Original-Received: from s.wrqvtzvf.outbound-mail.sendgrid.net ([149.72.126.143]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r4izT-0003KK-O1 for emacs-devel@gnu.org; Sun, 19 Nov 2023 09:41:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=7Jja2Zvb5qfEcatJtZeaZC/MuVEC9tjIRzN8VsmEHE8=; b=CfQ4FGsWAZoDr65HW+Oc//AUyMDZjEV9Wv0Hdhj8Zg+FNo0ZmGUqiQqngZ4cYFG1rx1E E317NQQwK09liXdlhZmnGUJCu73MCtKoGpzkMj8zP7MPINCwxnoNr+ZpsLsOQXx4ycPtwd /E2p2H6dyV0XhI5r/8jYq9NZgG778zRZGDIYhkdGDmY7GLpeqAndjPvVlFvJYRXkpJ5aCh Biyx98zDLO1BHhMPsUSukHzncTXoNr8KPfrWG/obVDL6040AN8348JMLgwrX0hZcm1NJf8 oQmjlPtQHaSn0FFXAJR53zBgz38hq8ikbl9Q0Fvjw5nyFWW7Vokoq1HblxsFw0Iw== Original-Received: by filterdrecv-656b5b4c75-gb89s with SMTP id filterdrecv-656b5b4c75-gb89s-1-655A1EA1-D 2023-11-19 14:41:37.773293342 +0000 UTC m=+2836906.570043014 Original-Received: from earth.catern.com (unknown) by geopod-ismtpd-35 (SG) with ESMTP id PXSqha_5T6qJsD3ACaqrlw Sun, 19 Nov 2023 14:41:37.536 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=74.101.51.129; helo=localhost; envelope-from=sbaugh@catern.com; receiver=linkov.net Original-Received: from localhost (unknown [74.101.51.129]) by earth.catern.com (Postfix) with ESMTPSA id 9823D62ED3; Sun, 19 Nov 2023 14:41:28 +0000 (UTC) In-Reply-To: <86sf52tf0b.fsf@mail.linkov.net> X-SG-EID: =?us-ascii?Q?GW3oCMoYnalRiojMOuLzE6x2H5kORXvlCdz1UwQVRMVT4fbh9ODEfCogOe74cO?= =?us-ascii?Q?rI4e0V+MFZgakz9Re5a6=2FCgpZE11395st5Gtazt?= =?us-ascii?Q?ZJUU1yiUWiPdq0vFMRvTYLnO4WJDGSj2J3j+uq+?= =?us-ascii?Q?LLbDwtVxIi2Xy10BS8hlXI+efd0W4X+C+COWwuq?= =?us-ascii?Q?z8ZqOkSKEQZsuAGHj5CdBSu=2FuQiuBdZnJF5aUmd?= =?us-ascii?Q?fYvxGZiHikD+zg1PHYYCIHRJc3ZgkmLgU+sAM9?= X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Received-SPF: pass client-ip=149.72.126.143; envelope-from=bounces+21787432-489d-emacs-devel=gnu.org@em8926.catern.com; helo=s.wrqvtzvf.outbound-mail.sendgrid.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001 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:312982 Archived-At: Juri Linkov writes: >> 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? I think we could provide some nice consistency by making it always active. As part of this change, I think we should make sure M-RET will submit a completion candidate even if it's been "deselected". That would be nice because then M-RET serves a useful purpose with minibuffer-visible-completions=t: you can submit the previously-selected completion candidate even if you've typed (causing deselection) since selecting it. With that M-RET behavior, completions-auto-update='deselect doesn't change behavior from Emacs 29, so I think it's a plausible default. And if we do have completions-auto-update='deselect by default, then perhaps we can consider another change to the defaults: make RET always submit the selected completion candidate. That would actually change behavior, since M- followed *immediately* by RET would submit the selected completion candidate, but maybe it's worth it? >> 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 Oh, yes, I definitely like the idea of not submitting the candidate when point is at the end, no need for any extra space. This would work well with my thought about having M-RET to submitting even a "deselected" candidate: the new behavior of not submitting a candidate when point is at the end would only be active for the new command minibuffer-choose-completion-or-exit. > (`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. This seems fine to me, but as Eli points out, terminal users probably won't like the extra "wasted" line. Maybe if we're in the terminal and there's no header, we could add a single space before the first completion?