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

[Juri Linkov]

> Though I'm starting to think that when require-match is nil, an
> icomplete user wouldn't want the new icomplete-show-matches-on-no-input
> behaviour anyway.

This is confusing, I don't understand why behaviour of
icomplete-show-matches-on-no-input should depend on require-match.

Here are two examples that produce a different result.

The first example is from hi-lock-read-face-name:

(defvar hi-history nil)
(icomplete-mode)
(let ((icomplete-show-matches-on-no-input t)
      (defaults '("hi-yellow" "hi-green"))
      (hi-history '("hi-blue")))
  (completing-read
   (format-prompt "Highlight using face" (car defaults))
   obarray 'facep t nil 'hi-history defaults))

displays this prompt:

  Highlight using face (default hi-yellow): {link | menu | bold ...

Typing RET returns "link" (and sometimes returns "hi-blue" from the history),
but never returns the expected default value "hi-yellow".

Whereas the second example from tab-bar-switch-to-tab
works correctly since its arg require-match is nil:

(let ((icomplete-show-matches-on-no-input t)
      (defaults '("yellow" "green"))
      (hi-history '("blue")))
  (completing-read
   (format-prompt "Switch to tab by name" (car defaults))
   defaults nil nil nil 'hi-history defaults))

displays this prompt:

  Switch to tab by name (default yellow): {green | yellow}

Typing RET returns the default value "yellow", not the first candidate "green".

This makes the behaviour of icomplete-show-matches-on-no-input
unpredictable, and thus in some cases dangerous.