As explained in the manual (20.7.2 Fast minibuffer selection)
'fido-mode' and 'fido-vertical-mode' give priority the "flex"
completion style.
In fact, bug#62015 was recently fixed in commit because that priority
was not taking place correctly and some completions were missed.
However, an exception must be made for the 'external' completion
style.
That style, made available by the lisp/external-completion.el library,
is specifically designed to work with backends that provide only a
partial view of all completions. If we allow 'flex' to step in front
of 'external' it could mean that 'flex' matches something and
'external' isn't triggered as it probably should.
To reproduce have the rust-mode ELPA package and the rust-analyzer LSP
server handy. Then:
emacs -Q -f package-initialize main.rs
Where main.rs is this content:
fn foo1() {} fn foo2() {} fn foo3() {}
fn foobar1() {} fn foobar2() {} fn foobar3() {}
The rust-analyzer server can be quickly configured to return only 3
workspace symbols max, so evaluate:
(setq-default eglot-workspace-configuration
'(:rust-analyzer
(:workspace (:symbol (:search (:limit 3))))))
Now start M-x eglot and M-x fido-vertical-mode and type C-u M-. to
find an arbitrary symbol in this one-file project.
Type 'f'. You will see the three foo's are listed, correctly.
Now type '3'. You will only see "foo3".
But that's wrong because "foobar3" was available, if only the server
had been asked for it. This commit fixes the situation and no
completions are lost.
As an unfortunate side-effect of this commit, the fontification of
completions-common-part on the matches is lost, but that is not worse
than missing out on completions and there are better ways to recover
the fontification anyway (in external-completion.el).
See also:
https://github.com/joaotavora/eglot/discussions/1219#discussioncomment-
5818336
* lisp/icomplete.el (icomplete--fido-ccd): Do not touch entries
with 'external in them.