bug#51650: Autocomplete: first Tab should show *Completions* buffer

[Carlos Pita <carlosjosepita@gmail.com>]

> We are mis-communicating.  Let's start from the beginning.
>
> Scenario #1:
>
>   . User presses C-x C-f TAB
>   . Emacs says [Complete but not unique]
>   . User presses TAB once more
>   . Emacs pops up *Completions* and still says [Complete but not unique]
>
> Scenario #2:
>
>   . User presses C-x C-f Desk TAB
>   . Emacs completes to ~/Desktop/
>   . User presses TAB once more
>   . Emacs pops up *Completions* and says [Complete but not unique]
>
> The difference after the first TAB is because in Scenario #1 there's
> nothing to complete, and what's in the minibuffer is already a valid
> response to the prompt: it specifies an existing file/directory.
> Whereas in Scenario #2 Emacs _can_ complete, and what the user typed
> is not an existing file.

So far so good, but I'm comparing the second Tab in scenario #2 to the
first Tab in scenario #1 because they are both in states characterized
by:

a. a valid response
b. a non-unique completion
c. no information yet communicated to the user about b

Of course one is in ~/ while the other is in ~/Desktop/,  so to make
my point clearer I've construed the alternative scenario:

Scenario #3:

  . User types M-x cd RET ~/Desktop RET (or launches emacs from ~/Desktop)
  . User presses C-x C-f TAB
  . Emacs says [Complete but not unique]
  . User presses TAB once more
  . Emacs pops up *Completions* and still says [Complete but not unique]

The way the user reached ~/Desktop in scenarios #2 and #3 is
irrelevant to me, the fact that s/he has typed Tab before or not is
not adding anything to the fact that the ongoing completion is now
~/Desktop/ and the user still doesn't know whether it's unique or not.
That's why I cannot make sense of the difference in behavior.