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

[sbaugh]

Juri Linkov <juri@linkov.net> writes:

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

How can this be the cause of bug#64903?  Wasn't that bug reproduced on
Emacs 28?  This change only went in to 29.