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

[Sean Whitton]

Hello,

The recent change to fix #19032 has broken my fido-mode workflow in a
way which I think reveals a bug.

When starting from an empty minibuffer, icomplete-fido-exit now selects
a different match depending on whether the completions have appeared
yet. So if you hit keys fast enough then you get different behaviour
than if you hit them a bit slower.

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 will take you to *GNU Emacs* but it should take you to foo (the
minibuffer prompt is "Switch to buffer (default foo)"). If you wait for
the completions to appear before hitting M-j, you go to the right place.

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.

--
Sean Whitton

[João Távora]

Sean Whitton <spwh...@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

[Sean Whitton]

Hello João,

On Mon 31 Aug 2020 at 12:50AM +01, João Távora wrote:

> Sean Whitton <spwh...@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.

Right. I actually have icomplete-fido-exit bound to RET because that
means that RET in any minibuffer always exits with the current input,
which I find makes completion less obstrusive. But this bug is breaking
that atm.

--
Sean Whitton

[Lars Ingebrigtsen]

João Távora <joaot...@gmail.com> writes:

> 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.

It was reported as a problem in icomplete, but I don't know how fido
relates to icomplete.

--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no

[Lars Ingebrigtsen]

Sean Whitton <spwh...@spwhitton.name> writes:

> 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.

Oh yeah, definitely -- it should be cleared on minibuffer exit. I'm
guessing that should go in... `completion--complete-and-exit'? Would
it be possible for you to propose a patch that does that? I don't use
fido-mode myself, and it's probably easier for you to test whether
that's the right fix.

[João Távora]

Lars Ingebrigtsen <la...@gnus.org> writes:

> João Távora <joaot...@gmail.com> writes:
>
>> 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.
>
> It was reported as a problem in icomplete, but I don't know how fido
> relates to icomplete.

This makes sense then. fido-mode is basically icomplete-mode with
different defaults and slightly different bindings, resulting in a
visual experience that looks vaguely like Ido (Fido = "fake Ido").

However, the description of this icomplete problem sounds like something
where fido-mode and icomplete-mode should exhibit exactly the same
behaviour, i.e. work along the very same code. So I'm baffled as to why
that problem affected icomplete and not fido-mode. Almost equally
baffled as to why it now breaks fido-mode.

I see in the side thread there seems to be a straightforward and logical
fix. If that makes sense globally and also fixes it for Sean, I'm fine
with it, otherwise I'd suggest having a second look at the original
problem that prompted the problematic patch, specifically at why
fido-mode didn't suffer from it.

João

[João Távora]

It didn't, but it sure does now.

I just noticed that this affects bare-bones fido-mode as well, i.e. even
without using M-j we get some akward and very highly annoying cache.

In an Emacs -Q with fido-mode enabled:

(bound-and-true-p [press C-h f RET here, slowly])

now move the point to the "setq" in, say

(setq blabla )

And type C-h f RET here, quickly. You'll be presented with
`bound-and-true-p`'s doc, not `setq`'s.

This is a regression: the bug should be fixed ASAP. Maybe some
"clearing" as was suggested is in order. I'm not very confortable
writing that patch right now. Can anyone else do it? Or should we
revert the original fix instead in the meantime?

João

[Lars Ingebrigtsen]

João Távora <joaot...@gmail.com> writes:

> This is a regression: the bug should be fixed ASAP. Maybe some
> "clearing" as was suggested is in order. I'm not very confortable
> writing that patch right now. Can anyone else do it? Or should we
> revert the original fix instead in the meantime?

I think the fix should be pretty trivial. I don't have time to test it
today, but tomorrow should be open.

Reverting the problematic patch in the meantime is fine by me, but on
the other hand, it'll get reapplied again tomorrowish, I guess, so that
seems like unnecessary churn...

[João Távora]

On Thu, Sep 3, 2020 at 2:11 PM Lars Ingebrigtsen <la...@gnus.org> wrote:

João Távora <joaot...@gmail.com> writes:

> This is a regression: the bug should be fixed ASAP.  Maybe some
> "clearing" as was suggested is in order.  I'm not very confortable
> writing that patch right now.  Can anyone else do it?  Or should we
> revert the original fix instead in the meantime?

I think the fix should be pretty trivial.  I don't have time to test it
today, but tomorrow should be open.

Reverting the problematic patch in the meantime is fine by me, but on
the other hand, it'll get reapplied again tomorrowish, I guess, so that
seems like unnecessary churn...

No problem then, but can you give me an idea of the patch, so

I can hotfix my Emacs master where this is bothering me a bit?

João

[Lars Ingebrigtsen]

João Távora <joaot...@gmail.com> writes:

> No problem then, but can you give me an idea of the patch, so
> I can hotfix my Emacs master where this is bothering me a bit?

I think setting the variable to nil in completion--complete-and-exit is
probably the correct fix, but I haven't tested it.

[João Távora]

Ok, thanks. I'll try that.

--

João Távora