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

[Juri Linkov <juri@linkov.net>]

>> 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':
>
> Any updates on the status of this patch?  I see you asked the same thing
> a year ago in one of those bugs.

A year ago I had a clear understanding how to do this but unfortunately
now forgot the details.  The idea was to return from completion-all-completions
not only '("string" . number) where number is the start of the completion position,
but something like '("string" . (number1 number2)) where the second number is
the end of the completion position.

completion-all-completions is called from minibuffer-completion-help.
Then the second number could help to set the right base-suffix in

  (setq-local completion-base-affixes
              (list base-prefix base-suffix))

This base-suffix is used later by M-<up> and M-<down>.
When here base-suffix is "", then your test case will be fixed.
However, non-empty base-suffix is necessary in other cases
such as mentioned in bug#48356:

  ~/emacs/master/li|/calc

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

Changing the API will definitely cause problems with backwards-compatibility.
But maybe you could find a simple heuristic that would decide what base-suffix
to set in minibuffer-completion-help?  Then no API changes will be needed.