bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer

[Juri Linkov]

>>> 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.
>
> How can this be the cause of bug#64903?  Wasn't that bug reproduced on
> Emacs 28?  This change only went in to 29.

bug#64903 is a related but completely separate case.

The patch above went in to master, so in-buffer completion
with non-nil completion-use-base-affixes is broken only
in master, but fortunately not broken in emacs-29.