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

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> catern.com, sbaugh <at> janestreet.com
Subject: bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer
Date: Sat, 08 Apr 2023 21:36:30 +0300

>> > 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.
>>
>> Thank you for the guidance and suggestion.
>>
>> Here's one heuristic which works decently well:
>
> If this is for master, I'm fine with such changes.  But if you intend
> to request installing this on emacs-29, then I will object making
> non-trivial changes in any code that is not specific to the M-<UP> and

Actually, a change for base-suffix in minibuffer-completion-help
is a trivial change.  What counts as a non-trivial change would be
changing the API in completion-all-completions.

> M-<DOWN> bindings that are new in Emacs 29.  I don't want to risk any
> regressions in general-purpose completion code at this late stage.

These changes are specific to the M-<UP> and M-<DOWN> bindings:
completion-use-base-affixes is nil, and it's let-bound to t
in M-<UP> (minibuffer-previous-completion) and M-<DOWN>
(minibuffer-next-completion).

Previous Next

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