bug#61535: 29.0.60; choose-completion erases in-region buffer

[Eli Zaretskii <eliz@gnu.org>]

> From: Juri Linkov <juri@linkov.net>
> Cc: 61535@debbugs.gnu.org
> Date: Fri, 17 Feb 2023 09:50:40 +0200
> 
> >> >> 1. type: (with-c C-M-i
> >> >> 2. type: M-down ... M-RET
> >> >> 3. check that the whole buffer was deleted before a selected
> >> >>    completion candidate was inserted to the buffer:
> >> >>    C-h v buffer-undo-list RET
> >> >
> >> > Which buffer was deleted? *scratch*?  It isn't here.
> >> >
> >> > And what does "C-h v buffer-undo-list RET" mean?
> >> >
> >> > Bottom line: I don't understand what is the bug here and/or how to
> >> > reproduce it.
> >>
> >> The contents of the *scratch* buffer is erased and replaced
> >> with the same text.  This fact can be confirmed by looking
> >> at the value of 'buffer-undo-list' that contains the text
> >> of the whole buffer as a string.  Especially this is noticeable
> >> when using in-region completion in a large buffer.
> >>
> >> With the patch, only the completed string is inserted.
> >
> > Thanks for the explanation.  Then please install this on master, since
> > AFAIU this is a very old problem, and it's just an aesthetic one.
> 
> Actually, this is not an old problem.  It's in a new feature added in 29.1.

Hmmm... I don't think I see that.  Both completion-in-region-mode and
the condition at that place haven't changed in a while.  The addition
of completion-use-base-affixes part is new, but since it's via 'and',
it cannot have changed what the code before did, only cause it to do
that in fewer cases.  What am I missing?

> And this patch fixes the new feature.  This is different from a similar
> problem fixed now in bug#61479 that is really an old problem.

This is all undecipherable for me, sorry.  What is that "new feature",
and how is it fixed here?  And how is bug#61479 relevant?