GNU bug report logs -
#62700
29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer
Previous Next
Reported by: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Thu, 6 Apr 2023 17:57:01 UTC
Severity: normal
Found in version 29.0.60
Fixed in version 30.0.50
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> Without this change, only the minibuffer contents before point are
> cleared when a completion is chosen, which results in stray text when
> point is in the middle of the minibuffer.
>
> After this change, we heuristically decide either to clear the whole
> buffer or only part of it, taking into account the location of point.
>
> diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
> index 539206a19e4..d079dc0bcdf 100644
> --- a/lisp/minibuffer.el
> +++ b/lisp/minibuffer.el
> @@ -2395,7 +2395,11 @@ minibuffer-completion-help
> (prefix (unless (zerop base-size) (substring string 0 base-size)))
> (base-prefix (buffer-substring (minibuffer--completion-prompt-end)
> (+ start base-size)))
> - (base-suffix (buffer-substring (point) (point-max)))
> + (base-suffix
> + (if (eq (alist-get 'category (cdr md)) 'file)
> + (buffer-substring (save-excursion (or (search-forward "/" nil t) (point-max)))
> + (point-max))
> + ""))
As was found in bug#64903, this change broke completion-in-region.
For example, with (setq completion-use-base-affixes t)
if there is some text in the current buffer after point,
then typing 'M-C-i' and selecting a candidate to insert to the buffer,
it replaces all the text after point with an empty string.
Before this change, the suffix was set to the text after point,
and after inserting the selected candidate the suffix was
re-inserted to the same buffer.
This bug report was last modified 1 year and 39 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.