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: sbaugh <at> catern.com
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: Mon, 24 Apr 2023 14:22:56 +0300

> From: sbaugh <at> catern.com
> Date: Sun, 23 Apr 2023 11:48:50 +0000 (UTC)
> Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> From: sbaugh <at> catern.com
> >> Date: Sat, 22 Apr 2023 21:38:52 +0000 (UTC)
> >> Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> > I asked for the changes to affect only code specific to M-<UP> and
> >> > M-<DOWN>, but the patch you posted doesn't limit itself to that,
> >> > AFAICT.  Or what am I missing?
> >> 
> >> Ah, I didn't realize that was what you were asking for.  I can do that,
> >> certainly, but why not also cover M-RET?  The bug exists in the exact
> >> same form for M-RET and it will be confusing (though better than
> >> nothing, definitely) if the fix applies to M-<UP> and M-<DOWN> but not
> >> M-RET.
> >
> > If the issue exists for M-RET, then fixing that case as well is okay.
> > The request was not to affect any code that handles also other
> > situation and other keys.
> 
> M-RET is bound to minibuffer-choose-completion, so then why the
> objection to a patch which affects minibuffer-choose-completion?

Because we never talked about M-RET until now?

Previous Next

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