bug#42101: icomplete-fido-ret doesn't always use minibuffer-default when input is empty

[Andrew Schwartzmeyer]

I’m sorry so João, I had sent you a repro last week, but it again didn’t go through.

It appears I have to leave TLS-sending guarantees disabled because the debbugs mail server is insecurely configured (for others who may be reading but offering no useful input, this is a security issue that does not exist with GitHub or other similar software). Perhaps we should move to emacs-devel which at least accepts email sent over TLS.

Anyway, I can repro this in emacs -Q with:

(defun fido-mode+ ()

  (setq-local completion-styles '(basic)))

(add-hook 'icomplete-minibuffer-setup-hook #'fido-mode+)

(fido-mode)

Basically (heh) this happens if the “basic” completion-style is used (or “partial-completion” or “substring” or any combination including one of those styles).

It only doesn’t repro if “flex” is used by itself (the default for fido-mode, but should be able to be overridden).

This also repros with icomplete-mode if “icomplete-show-matches-on-no-input” is t, as in:

(defun fido-mode+ ()

  (setq-local completion-styles '(basic)

              icomplete-show-matches-on-no-input t))

(add-hook 'icomplete-minibuffer-setup-hook #'fido-mode+)

(icomplete-mode)

Which explains why it’s readily apparent in fido-mode, where that’s set to t already. Unfortunately, I still have no clue how to fix it. I would appreciate your help! Being able to use the default styles in addition to flex makes the fido-mode experience smoother, because they return defaults for no input much faster, I find them to be more predictable, and it’s when they fail that flex tends to shine most.

Thanks,

Andy

On Jun 29, 2020, at 7:00 AM, João Távora <joaotavora@gmail.com> wrote:

Andrew Schwartzmeyer <andrew@schwartzmeyer.com> writes:

Hi,

Funny bug, haven’t figured out the cause. It may be hard to repro.

If you have some amount of minibuffer history, you can cause
icomplete-fido-ret to not accept the minibuffer-default. An example is
having history such that 'C-h v' when point is on ‘completion-styles’
causes ‘completion-styles-alist’ to be the first history
element. Since the minibuffer-default shows ‘completion-styles’ (being
that it’s under point, and I’ve not entered any text into the
minibuffer), I’d expect RET to choose ‘completion-styles’, but instead
it choses ‘completion-styles-alist’ (the head of the presented
candidates, ‘completion-styles’ is instead the second candidate).

This repros in fido-mode, but not icomplete-mode. I took a look at the
relevant functions called on RET for these modes but am having trouble
finding the issue.

I can't reproduce this.  I think the first step is for you to try to
identify which sequence of actions as performed from an Emacs
session started with -Q lead to the problem.  For the record, I tried

Emacs -Q (master of around two weeks ago)

 C-h v completion-styles RET
 C-h v completion-styles-alist RET

type "completion-styles" in *scratch* buffer.  With cursor on word.

 C-h v RET (quickly, before the completions appear)
 C-h v RET (slowly, letting the completions appear)

Both approaches lead to the variable `completion-styles` being
described.

João