GNU bug report logs -
#51650
Autocomplete: first Tab should show *Completions* buffer
Previous Next
Full log
View this message in rfc822 format
> 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.
This bug report was last modified 3 years and 198 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.