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.bugs Subject: bug#68801: 30.0.50; minibuffer-visible-completions=t makes RET in completion-in-region a no-op with nothing selected Date: Fri, 16 Feb 2024 09:34:17 -0500 Message-ID: References: <86y1c6688u.fsf@mail.linkov.net> <86plxiq6hv.fsf@mail.linkov.net> <867cjejfan.fsf@mail.linkov.net> <871q9k6vfo.fsf@catern.com> <867cjax4oc.fsf@mail.linkov.net> <87zfw6ogt2.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="34725"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 68801@debbugs.gnu.org, Juri Linkov To: sbaugh@catern.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 16 15:35:00 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1razIq-0008iq-72 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 16 Feb 2024 15:35:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1razIa-0002zG-GB; Fri, 16 Feb 2024 09:34:44 -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 1razIZ-0002yi-5c for bug-gnu-emacs@gnu.org; Fri, 16 Feb 2024 09:34:43 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1razIY-0002oF-Tf for bug-gnu-emacs@gnu.org; Fri, 16 Feb 2024 09:34:42 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1razIs-0002hs-5I for bug-gnu-emacs@gnu.org; Fri, 16 Feb 2024 09:35:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 16 Feb 2024 14:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68801 X-GNU-PR-Package: emacs Original-Received: via spool by 68801-submit@debbugs.gnu.org id=B68801.170809408510374 (code B ref 68801); Fri, 16 Feb 2024 14:35:02 +0000 Original-Received: (at 68801) by debbugs.gnu.org; 16 Feb 2024 14:34:45 +0000 Original-Received: from localhost ([127.0.0.1]:58138 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1razIb-0002hF-0D for submit@debbugs.gnu.org; Fri, 16 Feb 2024 09:34:45 -0500 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]:36215) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1razIY-0002h1-Qj for 68801@debbugs.gnu.org; Fri, 16 Feb 2024 09:34:43 -0500 In-Reply-To: <87zfw6ogt2.fsf@catern.com> (sbaugh@catern.com's message of "Sun, 11 Feb 2024 21:02:26 +0000 (UTC)") DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1708094058; bh=hvCYgHzp20EDx1OihCTHSIbQ3V3WzksTVqBcrrUqtgw=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=KUA6ffy0Jvddo2yNnYZUHbVxHCGiflEp5Jx1VIm8G2SB7c/6lN3m79BpvC4qOqYtG 9Gms2SPKuZ/iEGMzaeRQe9OkGf5vxK8NAuj7GDE792/CvlmBzT5XBqTCz7aWWRD5z/ /c6eiLk/403V+5DGUYkJQWcnwr8gfzSpLiwhqhl0KY9xg7IhoUuu0Lux5MP9E+lxvX IYOceWBZnIsYbxaFkXLRNHATgCyxWT5bwJrsQH4LTHB+wn/svbsXCMDyW7StemKWQ4 KXO2ynBSnp9ibz97IEN4i5u6NjTCmrplC6Pl0fQzho4M5L6n3NrB3xrk82+jXu5k4V nI3umXJ3jXajw== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:280101 Archived-At: sbaugh@catern.com writes: >>> Alternatively... as a completely separate point, I'd like >>> completion-in-region to select the first completion candidate by >>> default. I think that's useful in some cases and, for >>> completion-in-region, doesn't have any negatives: we couldn't do it in >>> the minibuffer because it would interfere with accepting the default, >>> but there are no defaults in completion-in-region. >>> >>> If we make c-i-r select the first completion candidate by default, that >>> would both: >>> >>> - Make the completion-show-help help render correctly with the "only >>> override RET when there's a selected completion" patch. >>> >>> - Partially mitigate the RET issue all on its own >> >> Calling 'first-completion' makes sense even for the minibuffer, >> at least optionally. > > What about this simple patch? > > If minibuffer-visible-completions=nil, it just calls first-completion. > This doesn't meaningfully change anything, since previously M-RET would > just no-op in that situation. And it's actually quite useful, because > it makes M-RET useful without having to ever actually do M-; one > can just type text to narrow the completions and then hit M-RET. Which > is sometimes nice. > > If minibuffer-visible-completions=t, it calls first-completion only when > there's no minibuffer-default; that way a simple RET will still select > the minibuffer default. > > diff --git a/lisp/simple.el b/lisp/simple.el > index 8246b9cab81..715ab672655 100644 > --- a/lisp/simple.el > +++ b/lisp/simple.el > @@ -10355,7 +10355,10 @@ completion-setup-function > "Type \\[minibuffer-choose-completion] on a completion to select it.\n"))) > (insert (substitute-command-keys > "Type \\[minibuffer-next-completion] or \\[minibuffer-previous-completion] \ > -to move point between completions.\n\n"))))))) > +to move point between completions.\n\n")))) > + (unless (and minibuffer-visible-completions minibuffer-default) > + (with-minibuffer-completions-window > + (first-completion)))))) > > (add-hook 'completion-setup-hook #'completion-setup-function) > I found selecting first-completion in the minibuffer to be annoying, so now I'm trying with the following instead (which also fixes the highlight to actually be shown): (defun minibuffer-cir-first-completion () "Move point to the first completion in the *Completions* window." (when completion-in-region-mode (with-selected-window (get-buffer-window standard-output 0) (when completions-highlight-face (setq-local cursor-face-highlight-nonselected-window t)) (first-completion)))) (add-hook 'completion-setup-hook #'minibuffer-cir-first-completion 90)