bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#43120: 28.0.50; fido-mode: M-j before completions appear selects wro


From: João Távora
Subject: bug#43120: 28.0.50; fido-mode: M-j before completions appear selects wrong choice
Date: Mon, 31 Aug 2020 00:50:10 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Sean Whitton <spwhitton@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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]