GNU bug report logs -
#55205
28.1.50; completion--replace illegally mutates completion candidates
Previous Next
Reported by: Daniel Mendler <mail <at> daniel-mendler.de>
Date: Sun, 1 May 2022 08:29:02 UTC
Severity: normal
Found in version 28.1.50
Done: Daniel Mendler <mail <at> daniel-mendler.de>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> I think it's much better to fix the bug, so I just pushed the patch
> below to `master`.
>
> I think it's safe enough for `emacs-28`, but I can't claim it's
> "obviously safe", the way I could about that same `copy-sequence` in
> `cl-generic.el`.
>
> diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
> index ef71b4e6be6..fb473cf71b0 100644
> --- a/lisp/minibuffer.el
> +++ b/lisp/minibuffer.el
> @@ -1140,6 +1140,7 @@ completion--replace
> ;; The properties on `newtext' include things like the
> ;; `completions-first-difference' face, which we don't want to
> ;; include upon insertion.
> + (setq newtext (copy-sequence newtext)) ;Don't modify the arg by side-effect.
> (if minibuffer-allow-text-properties
> ;; If we're preserving properties, then just remove the faces
> ;; and other properties added by the completion machinery.
Thanks, Stefan! This is the proper fix. I also think this is safe enough
for the emacs-28 branch. It will also fix the icomplete bug there, where
minibuffer-force-complete *incorrectly* strips the text properties.
Daniel
This bug report was last modified 232 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.