GNU bug report logs - #43120
28.0.50; fido-mode: M-j before completions appear selects wrong choice

Previous Next

Full log

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

From: João Távora <joaotavora <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: larsi <at> gnus.org, 43120 <at> debbugs.gnu.org
Subject: Re: bug#43120: 28.0.50; fido-mode: M-j before completions appear
 selects wrong choice
Date: Mon, 31 Aug 2020 00:50:10 +0100

Sean Whitton <spwhitton <at> spwhitton.name> writes:

> For example:
>
> 1. emacs -q
> 2. M-x fido-mode RET
> 3. C-x b foo M-j (type slowly)
> 4. C-x b bar M-j (type slowly)
> 5. C-x b M-j (type quickly)

This sounds like a bug, indeed.  I dealt with this kind of problem in
the past and worked hard to mitigate it.  I was unware of this recent
patch to icomplete/fido-mode, sorry.

I will note that the problem doesn't seem to happen if step 5 ends with
RET instead of M-j.  M-j in the fido-mode minibuffer is bound to
icomplete-fido-exit which does have have an optional FORCE arg, which
could maybe justify the behaviour you're observing.  But anyway it's nil
by default, so it doesn't.

> I think the fix would be to clear completion-content-when-empty when the
> minibuffer exits, instead of leaving data from the last completion
> there.  Or possibly M-j should call icomplete-completions to popular
> completion-content-when-empty with the correct information.

I don't understand the reason of being for the patch.  I didn't read the
bug, but I do read this in NEWS:

    +*** 'icomplete-show-matches-on-no-input' behavior change
    +Previously, choosing a different completion with commands like 'C-.'
    +and then hitting enter would choose the default completion.  Doung
    +this will now choose the completion under point.

Now, I have never observed this reported behaviour in fido-mode even
before the patch.

João

Previous Next

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