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: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
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 22:32:34 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: sbaugh <at> catern.com,  62700 <at> debbugs.gnu.org,  sbaugh <at> janestreet.com
> Date: Sat, 08 Apr 2023 21:36:30 +0300
> 
> > 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).

The change I reviewed and to which I responded was in code that was
there in Emacs 28 as well.  Maybe we are talking about two different
sets of changes.

Previous Next

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