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

> Here's one heuristic which works decently well:
>
> The reasoning here is that if completion returns the full string which
> should be in the minibuffer, then we should replace the minibuffer with
> that string, so base-suffix should be "".  But if we're completing only
> part of the string, base-suffix should be something else.  AFAIK only
> file completion falls into the latter category, and it always completes
> just one component of a path, so I set base-suffix to not include the
> component of the path that point is in, so that completion replaces it
> entirely.
>
> I think this is basically a satisfactory heuristic, although I'm sure
> I'm missing some categories of completion besides file completion which
> complete only part of the string.

Thanks, this looks like a satisfactory heuristic indeed.  It just needs
more testing for different categories of completion.

> Regardless of whether this is a satisfactory heuristic, it's revealed to
> me an unexpected behavior of a solution to this bug using base-suffix,
> which may or may not be fine: Point is moved to the end of the
> completion inserted.
>
> So e.g. if point is at | and I'm completing |-path, then when I choose
> the completion load-path, point will be at load-path| rather than
> load|-path.  This isn't a huge issue but it might be a little annoying?
> I don't know if there's any way to fix this.

Maybe you could find another heuristic for insertion of completion?
The code is located in the same function 'minibuffer-completion-help':

  (if (and (stringp start) (stringp end))
      (progn
        (delete-minibuffer-contents)
        (insert start choice)
        ;; Keep point after completion before suffix
        (save-excursion (insert end)))

Currently it keeps point before the suffix.