From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Spencer Baugh <sbaugh@janestreet.com>
Cc: 74019@debbugs.gnu.org, Juri Linkov <juri@linkov.net>
Subject: bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update
Date: Sat, 26 Oct 2024 10:49:19 -0400 [thread overview]
Message-ID: <jwv4j4zszth.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <ier1q03x409.fsf@janestreet.com> (Spencer Baugh's message of "Fri, 25 Oct 2024 17:32:38 -0400")
> Add completion-preserve-selection, a defcustom which allows keeping the
> same selected candidate after *Completions* is updated by
> minibuffer-completion-help.
IIUC, this is a change that affects only `minibuffer-completion-help`,
which is part of the standard UI's *Completions*, right, the generic
completion infrastructure, right?
> This works correctly with choose-completion-deselect-if-after: If point
> is after a completion (such that choose-completion-deselect-if-after=t
> means it won't be treated as selected), point will still be after that
> completion after updating the list.
I can't remember what `choose-completion-deselect-if-after` is about,
sorry, but the above reads like "the code doesn't have one of the bugs
I encountered while implemented the code". Is there more to this paragraph?
> This feature is primarily motivated by the fact that some other
> completion UIs (e.g. ido, vertico, etc) effectively have this behavior:
> whenever they update the list of completions, they preserve whatever
> candidate is selected.
Are there cases where the current behavior is preferable?
IOW, why do we need a config var and why does it default to nil?
> * lisp/minibuffer.el (completion-preserve-selection):
> (minibuffer-completion-help):
> (minibuffer-next-completion):
> * lisp/simple.el (choose-completion):
> (completion-setup-function):
I presume you know that this is incomplete. 🙂
[ BTW, I really regret not moving the `completion-list-mode` out of
`simple.el`. ]
> + "If non-nil, `minibuffer-completion-help' preserves the selected completion candidate.
> +
> +If non-nil, and point is on a completion candidate in the displayed
> +*Completions* window, `minibuffer-completion-help' will put point on the
> +same candidate after updating *Completions*."
I think we should be more clear that it *tries* to preserve it.
After all, the selected candidate may simply be absent from the new set
of candidates.
> @@ -2624,6 +2634,12 @@ minibuffer-completion-help
> (sort-fun (completion-metadata-get all-md 'display-sort-function))
> (group-fun (completion-metadata-get all-md 'group-function))
> (mainbuf (current-buffer))
> + (current-candidate-and-offset
> + (when-let* ((window (get-buffer-window "*Completions*" 0)))
> + (with-selected-window window
> + (when-let* ((beg (completions--start-of-candidate-at (point))))
> +
> + (cons (get-text-property beg 'completion--string) (- (point) beg))))))
> ;; If the *Completions* buffer is shown in a new
> ;; window, mark it as softly-dedicated, so bury-buffer in
> ;; minibuffer-hide-completions will know whether to
Hmm... are we sure here that the `*Completions*`s content is related to
the current completion session? I don't think we want to preserve the
selection when it came from an unrelated use of completion half an
hour earlier.
> @@ -4905,8 +4928,6 @@ minibuffer-next-completion
> (interactive "p")
> (let ((auto-choose minibuffer-completion-auto-choose))
> (with-minibuffer-completions-window
> - (when completions-highlight-face
> - (setq-local cursor-face-highlight-nonselected-window t))
> (if vertical
> (next-line-completion (or n 1))
> (next-completion (or n 1)))
[...]
> @@ -10451,6 +10458,8 @@ completion-setup-function
> (let ((base-position completion-base-position)
> (insert-fun completion-list-insert-choice-function))
> (completion-list-mode)
> + (when completions-highlight-face
> + (setq-local cursor-face-highlight-nonselected-window t))
> (setq-local completion-base-position base-position)
> (setq-local completion-list-insert-choice-function insert-fun))
> (setq-local completion-reference-buffer mainbuf)
Why?
Stefan
next prev parent reply other threads:[~2024-10-26 14:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-25 21:32 bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-26 6:45 ` Eli Zaretskii
2024-10-26 14:59 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-28 14:08 ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-27 7:55 ` Juri Linkov
2024-10-28 13:57 ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-26 14:49 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-10-28 13:51 ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-28 14:21 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-28 16:01 ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-29 2:53 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-29 16:25 ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-29 18:27 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwv4j4zszth.fsf-monnier+emacs@gnu.org \
--to=bug-gnu-emacs@gnu.org \
--cc=74019@debbugs.gnu.org \
--cc=juri@linkov.net \
--cc=monnier@iro.umontreal.ca \
--cc=sbaugh@janestreet.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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).