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

[Spencer Baugh <sbaugh@janestreet.com>]

Juri Linkov <juri@linkov.net> writes:
>> 6. C-h v -path
>> 7. C-a to move point to before -path
>> 8. <tab> to show completions of variables ending in -path
>> 9. Use M-<up> and M-<down> to switch between completions.  Now as you
>> switch completions, they are inserted at point, *without* replacing the
>> text already in the buffer.  So e.g. the minibuffer will contain
>> "load-path-path".
>> 10. Likewise, if you (setq minibuffer-completion-auto-choose nil), M-RET
>> inserts the completion string at point, without replacing the text in
>> the minibuffer, so you will get "load-path-path".
>>
>> I think this is basically just a bug.  Hopefully we can fix this before
>> Emacs 29 is released, because this is the last thing which stops these
>> new commands from being a really great improvement to the Emacs
>> completion defaults.
>
> I agree that it would be nice to fix this in Emacs 29.
> But the problem is that this would require non-trivial changes.
> We need to apply a small part of the patch mentioned in
> bug#47711, bug#48356, bug#48841, bug#60313 and located at
> https://lists.gnu.org/archive/html/emacs-devel/2021-08/msg00412.html
> that implements the following FIXME item in 'completion-all-completions':
>
>   ;; FIXME: We need to additionally return the info needed for the
>   ;; second part of completion-base-position.
>
> When it will return from 'completion-all-completions' not only the start
> position of a completion, but also its end, then we could use this
> additional information for M-<up> and M-<down>.

Any updates on the status of this patch?  I see you asked the same thing
a year ago in one of those bugs.

I can try to prepare a more minimal version of this patch, just targeted
at adding the ability to return the end of the completion position.

Do you have any advice on an appropriate API for that?  An alist as in
that patch seems reasonable to me, but perhaps there's an even simpler
approach?

(BTW, the reason I really want to fix this in Emacs 29 is that I don't
want us to be concerned with being backwards-compatible with the current
behavior in 29, which seems much worse to me.  But if we won't be
concerned about that, doing this in 30 seems totally fine.  I can just
backport it for my users anyway :) )