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 <mailto: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