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

Previous Next

Full log

Message #26 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 62700 <at> debbugs.gnu.org
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Fri, 07 Apr 2023 19:37:51 +0300

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.