unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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






  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).