all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Spencer Baugh <sbaugh@janestreet.com>
To: sbaugh@catern.com
Cc: 68801@debbugs.gnu.org, Juri Linkov <juri@linkov.net>
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	[thread overview]
Message-ID: <iera5o01nrq.fsf@janestreet.com> (raw)
In-Reply-To: <87zfw6ogt2.fsf@catern.com> (sbaugh@catern.com's message of "Sun,  11 Feb 2024 21:02:26 +0000 (UTC)")

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-<down>; 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)






  reply	other threads:[~2024-02-16 14:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-29 18:49 bug#68801: 30.0.50; minibuffer-visible-completions=t makes RET in completion-in-region a no-op with nothing selected Spencer Baugh
2024-01-30 17:28 ` Juri Linkov
2024-01-30 20:21   ` Spencer Baugh
2024-01-31  7:58     ` Juri Linkov
2024-02-09  7:17       ` Juri Linkov
2024-02-10 18:14         ` sbaugh
2024-02-11 17:59           ` Juri Linkov
2024-02-11 21:02             ` sbaugh
2024-02-16 14:34               ` Spencer Baugh [this message]
2024-02-18  7:46                 ` Juri Linkov
2024-02-26 16:04           ` Spencer Baugh
2024-02-27 20:45             ` Spencer Baugh
2024-02-29 17:56               ` Juri Linkov
2024-03-15  7:41                 ` Juri Linkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=iera5o01nrq.fsf@janestreet.com \
    --to=sbaugh@janestreet.com \
    --cc=68801@debbugs.gnu.org \
    --cc=juri@linkov.net \
    --cc=sbaugh@catern.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.