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: sbaugh <at> catern.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
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 10:58:36 +0000 (UTC)

Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: 62700 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> janestreet.com>
>> From: sbaugh <at> catern.com
>> Date: Fri, 07 Apr 2023 21:02:47 +0000 (UTC)
>> 
>> Juri Linkov <juri <at> linkov.net> writes:
>> > 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
> 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.

OK, that's no problem, this can be done by just let-binding
completion-base-affixes in minibuffer-{previous,next,choose}-completion
so that it only affects new code.  That will be a bit uglier to read so
I'll do that if this approach seems reasonable with some review.

Previous Next

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