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

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

[Carlos Pita]

Hi all,

I might be wrong here, but I believe find-file and friends work in a
way that is a bit inconvenient as well as a bit inconsistent.

For example:

1. I press C-x C-f and get "Find file: ~/"
2. I press Tab once and get the message "Complete, but not unique"
3. I press Tab again and the *Completions* buffer appears with
candidate completions.
4. I type "Desk" and press Tab.
5. Now I'm at ~/Desktop/ and press Tab again.
6. I get the message "Complete, but not unique" but at the same time
the *Completions* buffer is displayed.

Now, this is inconvenient since the first time I have to type Tab twice
in order to get the *Completions* buffer (or ?, which is not very
handy in most keyboards). AFAICS the first Tab does nothing at all
except in the rare situation when there is a single completion, in
other cases the inference that the user could use some help seems not
too far-fetched to me.

And this also might be seen as inconsistent in that the second time
the same Tab shows both the "not unique" message and the help buffer,
which is IMO a more sensible behavior.

I think that Tab in step 2 should show the message and the list of
possible completions at the same time.

What do you think?

Best regards,
Carlos

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

[Carlos Pita]

> What do you think?

And if you don't agree, how do you make sense of the described behavior?

For example, here is an explanation: a Tab not preceded by another Tab
means "complete whenever possible" while two Tabs in a row always mean
"show possible completions" (even if the first Tab was "captured" by a
completion). This explanation is based on my reading of the
implementation, but the manual says something different:

> TAB: Complete the text in the minibuffer as much as possible;
> if unable to complete, display a list of possible completions

According to this sentence I would expect that the Tab in point 2,
which is unable to complete anything, displayed a list of possible
completions. One can always argue that the Tab indeed completes "",
but that seems forced to me and, in any case, the same can be said of
3 and 5.

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

[Eli Zaretskii]

> From: Carlos Pita <carlosjosepita@gmail.com>
> Date: Sun, 7 Nov 2021 02:09:46 -0300
> 
> > What do you think?
> 
> And if you don't agree, how do you make sense of the described behavior?

Please see the manual, it explains that (I think).  File-name
completion is different from other kinds of completion.

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

[Carlos Pita]

Hi Eli,

> This is a long-standing behavior, which is very convenient with file
> names.  It is documented in the node "Completion Exit" in the Emacs
> manual.

I had read that node before posting but I still fail to see how it is
related to my point, because the node is about pressing Return to exit
the completion, but in my example I don't want to exit anything and
I'm just repeatedly pressing Tab.

> That'd get in the way of selecting the "complete, but not unique"
> candidate.  It is also a distraction.

I'm likely misunderstanding something, but the behavior you object
here seems very similar to the one in step 5 of my example. In step 5
there is a Tab that fails to complete and _at the same time_ both the
"not unique" message and the completion candidates are shown. This Tab
was preceded by a completing Tab. The difference with the Tab in step
2 is that this one was the first one and so not preceded by any other
Tab. In both cases (step 2 and step 5) the Tab may have succeeded or
failed to complete by similar reasons, in my example both actually
failed, still their behaviors differ.

I can understand why things work the way they do by looking at the
implementation. But I can't put it into simple meaningful reasons. The
manual says that when Tab is unable to complete it displays a list of
possible completions, yet in step 2 this is not true. The
implementation checks that the last command and the current command
are the same before showing that list of completions, so it surely
won't happen in step 2 since it's the first and only Tab in the
sequence. In order to explain this, one seems forced to say that _at
least_ two Tabs in a row have to be pressed to show the *Completions*
buffer: one won't do it, exactly two won't always do it (both of them
may complete something), so there must be a sequence of at least two
Tabs and the last one must be unable to complete.

But why? Perhaps I'm misunderstanding the manual because of that note
you mentioned, but then again how is the exit behavior relevant to my
argument?

Thank in advance,
Carlos

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

[Eli Zaretskii]

> From: Carlos Pita <carlosjosepita@gmail.com>
> Date: Sun, 7 Nov 2021 05:16:50 -0300
> Cc: 51650@debbugs.gnu.org
> 
> I can understand why things work the way they do by looking at the
> implementation. But I can't put it into simple meaningful reasons. The
> manual says that when Tab is unable to complete it displays a list of
> possible completions, yet in step 2 this is not true.

That's because TAB _is_ able to complete, but only partially.  And
with file names, it can well be that the partial match is what you
want.

> The implementation checks that the last command and the current
> command are the same before showing that list of completions, so it
> surely won't happen in step 2 since it's the first and only Tab in
> the sequence. In order to explain this, one seems forced to say that
> _at least_ two Tabs in a row have to be pressed to show the
> *Completions* buffer: one won't do it, exactly two won't always do
> it (both of them may complete something), so there must be a
> sequence of at least two Tabs and the last one must be unable to
> complete.

The 2 TABs are necessary if the partial completion is not what you
want.  Emacs cannot know that, only you, the user, can.

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

[Carlos Pita]

> > *Completions* buffer: one won't do it, exactly two won't always do
> > it (both of them may complete something), so there must be a
> > sequence of at least two Tabs and the last one must be unable to
> > complete.
>
> The 2 TABs are necessary if the partial completion is not what you
> want.  Emacs cannot know that, only you, the user, can.

But then, by the same token, why is this not true of step 5?

There I'm in ~/Desktop coming from a previous completing Tab, a "not
unique" message was not yet shown, I might press Tab again and get
another completion (perhaps there is a single subdirectory of
~/Desktop, perhaps all subdirectories share a common prefix) or not
(by far the most likely case). I press Tab and get "not unique" plus
candidates.

Suppose I now abort the process and do `M-x cd ~/Desktop` and then
enter the find-file completion again, I'm in the same situation, yet I
press Tab and I get "not unique" and I have to press Tab again in
order to get the list of candidates. Why should the behavior differ?
The only difference is that current != previous command, but that
seems hardly relevant to the matter.

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

[Eli Zaretskii]

> From: Carlos Pita <carlosjosepita@gmail.com>
> Date: Sun, 7 Nov 2021 05:39:40 -0300
> Cc: 51650@debbugs.gnu.org
> 
> > > *Completions* buffer: one won't do it, exactly two won't always do
> > > it (both of them may complete something), so there must be a
> > > sequence of at least two Tabs and the last one must be unable to
> > > complete.
> >
> > The 2 TABs are necessary if the partial completion is not what you
> > want.  Emacs cannot know that, only you, the user, can.
> 
> But then, by the same token, why is this not true of step 5?

Because in Step 5 you typed something, whereas in Step 2 you didn't
type anything.

> Suppose I now abort the process and do `M-x cd ~/Desktop` and then
> enter the find-file completion again, I'm in the same situation, yet I
> press Tab and I get "not unique" and I have to press Tab again in
> order to get the list of candidates. Why should the behavior differ?

Because you haven't typed anything yet, so Emacs doesn't know what you
have in mind.  In the other case, it has some hint.

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

[Carlos Pita]

Hi Eli,

I remain unconvinced. I'll restate the above in a slightly more
precise manner, but other than that I have nothing to add and if this
is getting tiresome by all means feel free to close it.

> > Suppose I now abort the process and do `M-x cd ~/Desktop` and then
> > enter the find-file completion again, I'm in the same situation, yet I
> > press Tab and I get "not unique" and I have to press Tab again in
> > order to get the list of candidates. Why should the behavior differ?
>
> Because you haven't typed anything yet, so Emacs doesn't know what you
> have in mind.  In the other case, it has some hint.

For me the relevant state includes:

- I'm in the ~/Desktop directory.
- I've not yet received any information about ~/Desktop being unique or not.

By adding one of:

- I've reached ~/Desktop from ~/Desk by pressing Tab.
- I've reached ~/Desktop by launching Emacs from ~/Desktop.
- I've reached ~/Desktop by changing the working directory.
etc.

... or, more succinctly:

- I've reached ~/Desktop by (immediately before) pressing Tab during
the same "completing session".
- I've reached ~/Desktop by other means.

... I can make the relevant state different, but I cannot grasp how
the added information is relevant. You say in the first case I have
typed something, namely Tab, but that was in a different context
(~/Desk) and I don't find it more relevant than the fact that I have
typed "M-x cd ~/Desktop" in the second example. What's that thing that
the user has in mind?

If the "not unique" message were shown at the end of step 4 instead,
that would make an arguably relevant difference. In this variant, the
first Tab (both in 2 and in 4) is always the one conveying the "not
unique" hint, in 2 it's required only for this. Now in step 5 the
information set includes: "I know that ~/Desktop is not unique", while
this information is missing from the scenario in which I reached
~/Desktop by, say, launching emacs from that directory. I still find
this inconvenient but it's a way of resolving what I see as
inconsistent.

Another way is to make the behavior in 2 as the one in 5, that is to
require one Tab in 2 and show "not unique" and completions at
the same moment, it is the variant I prefer.

A third, uber annoying way, is to make the behavior in 5 as the one in
2, that is to require two Tabs in 5, so going from ~/Desk to the
completion menu for ~/Desktop would require three Tabs.

Best regards,
Carlos

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

[Eli Zaretskii]

> From: Carlos Pita <carlosjosepita@gmail.com>
> Date: Sun, 7 Nov 2021 15:40:22 -0300
> Cc: 51650@debbugs.gnu.org
> 
> I remain unconvinced. I'll restate the above in a slightly more
> precise manner, but other than that I have nothing to add and if this
> is getting tiresome by all means feel free to close it.
> 
> > > Suppose I now abort the process and do `M-x cd ~/Desktop` and then
> > > enter the find-file completion again, I'm in the same situation, yet I
> > > press Tab and I get "not unique" and I have to press Tab again in
> > > order to get the list of candidates. Why should the behavior differ?
> >
> > Because you haven't typed anything yet, so Emacs doesn't know what you
> > have in mind.  In the other case, it has some hint.
> 
> For me the relevant state includes:
> 
> - I'm in the ~/Desktop directory.
> - I've not yet received any information about ~/Desktop being unique or not.
> 
> By adding one of:
> 
> - I've reached ~/Desktop from ~/Desk by pressing Tab.
> - I've reached ~/Desktop by launching Emacs from ~/Desktop.
> - I've reached ~/Desktop by changing the working directory.
> etc.
> 
> ... or, more succinctly:
> 
> - I've reached ~/Desktop by (immediately before) pressing Tab during
> the same "completing session".
> - I've reached ~/Desktop by other means.
> 
> ... I can make the relevant state different, but I cannot grasp how
> the added information is relevant. You say in the first case I have
> typed something, namely Tab, but that was in a different context
> (~/Desk) and I don't find it more relevant than the fact that I have
> typed "M-x cd ~/Desktop" in the second example. What's that thing that
> the user has in mind?
> 
> If the "not unique" message were shown at the end of step 4 instead,
> that would make an arguably relevant difference. In this variant, the
> first Tab (both in 2 and in 4) is always the one conveying the "not
> unique" hint, in 2 it's required only for this. Now in step 5 the
> information set includes: "I know that ~/Desktop is not unique", while
> this information is missing from the scenario in which I reached
> ~/Desktop by, say, launching emacs from that directory. I still find
> this inconvenient but it's a way of resolving what I see as
> inconsistent.
> 
> Another way is to make the behavior in 2 as the one in 5, that is to
> require one Tab in 2 and show "not unique" and completions at
> the same moment, it is the variant I prefer.
> 
> A third, uber annoying way, is to make the behavior in 5 as the one in
> 2, that is to require two Tabs in 5, so going from ~/Desk to the
> completion menu for ~/Desktop would require three Tabs.

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.

OK?

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

[Carlos Pita]

> 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.

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

[Eli Zaretskii]

> From: Carlos Pita <carlosjosepita@gmail.com>
> Date: Sun, 7 Nov 2021 16:34:29 -0300
> Cc: 51650@debbugs.gnu.org
> 
> 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

But the difference is that until the first TAB the user cannot know
whether there is any completion.  Only after Emacs doesn't complete is
that fact known.  And that's the reason for the difference in
behavior.

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

[Carlos Pita]

> But the difference is that until the first TAB the user cannot know
> whether there is any completion.  Only after Emacs doesn't complete is
> that fact known.

First of all, I'm assuming:

- The initial value is taken from the current working directory so
it's always a valid completion.
- TAB never completes across the directory boundary.

Let's consider:

- TAB on ~/ (i.e. first TAB in #1)
- TAB on ~/Desktop/ after TAB-completing from ~/Desk (i.e.
second TAB in #2)
- TAB on ~/Desktop/ with cwd = ~/Desktop/ (i.e. first TAB in #3).

AFAICS these statements are true at the beginning (before pressing
TAB) of all cases:

- The user knows the current completion is valid.
- The user cannot know whether there is any other completion with the
same prefix.

You seem to be saying that the TAB that produced ~/Desktop/ from
~/Desk is adding some worthy information about the contents of
~/Desktop, and therefore about possible completions, that
wouldn't be there if the user, say, launched emacs from ~/Desktop
as in #3. But, for the life of me, I cannot see it :(

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

[Eli Zaretskii]

> From: Carlos Pita <carlosjosepita@gmail.com>
> Date: Sun, 7 Nov 2021 17:27:58 -0300
> Cc: 51650@debbugs.gnu.org
> 
> > But the difference is that until the first TAB the user cannot know
> > whether there is any completion.  Only after Emacs doesn't complete is
> > that fact known.
> 
> First of all, I'm assuming:
> 
> - The initial value is taken from the current working directory so
> it's always a valid completion.

The completion doesn't know that.  It's just what the caller arranged
for it to display.

> - TAB never completes across the directory boundary.

But it can complete less than that.

> You seem to be saying that the TAB that produced ~/Desktop/ from
> ~/Desk is adding some worthy information about the contents of
> ~/Desktop, and therefore about possible completions, that
> wouldn't be there if the user, say, launched emacs from ~/Desktop
> as in #3. But, for the life of me, I cannot see it :(

The completion doesn't know where it was launched from.  It just knows
what the user typed, and in the "~/" case the user didn't type
anything.

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

[Lars Ingebrigtsen]

Would it be possible to add a user option to make the first tab also
show the *Completions* buffer?

I agree with Eli that Emacs is working as designed here, but I think
some users would find it more logical if the first tab was more
aggressive.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Carlos Pita]

On Sun, Nov 7, 2021 at 5:39 PM Eli Zaretskii <eliz@gnu.org> wrote:
>

> > - The initial value is taken from the current working directory so
> > it's always a valid completion.
>
> The completion doesn't know that.  It's just what the caller arranged
> for it to display.
> [...]
> The completion doesn't know where it was launched from.  It just knows
> what the user typed, and in the "~/" case the user didn't type
> anything.

If we add the context that we're doing directory completion from the
cwd my statement is true. If we remove that context I start to see
where you're coming from. Let's say the algorithm is more generic and
unaware of some facts like its initial value being valid. From its
perspective it may start with an invalid response that's not even a
prefix of a valid response. After the TAB that goes from ~/Desk to
~/Desktop/ at least it knows that the response is the prefix of some
set of valid completions. So you may explain its behavior as:

1. C-x C-f => ~/ but from what I know this may be rubbish
2. TAB => ~/ ok this is a completion but there are more with the same prefix
3. TAB => ~/ as I said there are more with the same prefix, take a
look at the other ones
4. Desk<TAB> => ~/Desktop/ ok this is a completion
5. TAB => ~/Desktop/ there are more with the same prefix, take a look
at the other ones

At this level of explanation, there is a difference between the TAB in
2 and the TAB in 5. I also get why you may be willing to say that from
1 to 2 a completion indeed happened when, on the face of it, this
seems a nonsensical statement: the algorithm inspected a completion
set at this point and realized that the initial value is a member of
it. It's hardly what the manual conveys to a user unaware of the
implementation, but I get it. I still don't get why 2 and 3 can't be
merged into a single step but that would be a discussion about
convenience, at least I'm satisfied with this logical tackle on the
inconsistency issue.

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

[Stephen Berman]

On Sun, 7 Nov 2021 18:24:56 -0300 Carlos Pita <carlosjosepita@gmail.com> wrote:

> On Sun, Nov 7, 2021 at 5:39 PM Eli Zaretskii <eliz@gnu.org> wrote:
>>
>
>> > - The initial value is taken from the current working directory so
>> > it's always a valid completion.
>>
>> The completion doesn't know that.  It's just what the caller arranged
>> for it to display.
>> [...]
>> The completion doesn't know where it was launched from.  It just knows
>> what the user typed, and in the "~/" case the user didn't type
>> anything.
>
> If we add the context that we're doing directory completion from the
> cwd my statement is true. If we remove that context I start to see
> where you're coming from. Let's say the algorithm is more generic and
> unaware of some facts like its initial value being valid. From its
> perspective it may start with an invalid response that's not even a
> prefix of a valid response. After the TAB that goes from ~/Desk to
> ~/Desktop/ at least it knows that the response is the prefix of some
> set of valid completions. So you may explain its behavior as:
>
> 1. C-x C-f => ~/ but from what I know this may be rubbish
> 2. TAB => ~/ ok this is a completion but there are more with the same prefix
> 3. TAB => ~/ as I said there are more with the same prefix, take a
> look at the other ones
> 4. Desk<TAB> => ~/Desktop/ ok this is a completion
> 5. TAB => ~/Desktop/ there are more with the same prefix, take a look
> at the other ones
>
> At this level of explanation, there is a difference between the TAB in
> 2 and the TAB in 5. I also get why you may be willing to say that from
> 1 to 2 a completion indeed happened when, on the face of it, this
> seems a nonsensical statement: the algorithm inspected a completion
> set at this point and realized that the initial value is a member of
> it. It's hardly what the manual conveys to a user unaware of the
> implementation, but I get it. I still don't get why 2 and 3 can't be
> merged into a single step but that would be a discussion about
> convenience, at least I'm satisfied with this logical tackle on the
> inconsistency issue.

In fact, 2 and 3 essentially do get merged by setting
insert-default-directory to nil: then `C-x C-f' displays no directory in
the prompt, and the first TAB pops up the *Completions* buffer
containing completions in the default directory (unless it's empty or
contains only one file).  This seems to refute the contention that the
crucial difference between 2 and 5 is that in the former the user didn't
type anything.

Steve Berman

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

[Eli Zaretskii]

> From: Carlos Pita <carlosjosepita@gmail.com>
> Date: Sun, 7 Nov 2021 01:27:44 -0300
> 
> I might be wrong here, but I believe find-file and friends work in a
> way that is a bit inconvenient as well as a bit inconsistent.
> 
> For example:
> 
> 1. I press C-x C-f and get "Find file: ~/"
> 2. I press Tab once and get the message "Complete, but not unique"
> 3. I press Tab again and the *Completions* buffer appears with
> candidate completions.
> 4. I type "Desk" and press Tab.
> 5. Now I'm at ~/Desktop/ and press Tab again.
> 6. I get the message "Complete, but not unique" but at the same time
> the *Completions* buffer is displayed.
> 
> Now, this is inconvenient since the first time I have to type Tab twice
> in order to get the *Completions* buffer (or ?, which is not very
> handy in most keyboards). AFAICS the first Tab does nothing at all
> except in the rare situation when there is a single completion, in
> other cases the inference that the user could use some help seems not
> too far-fetched to me.

This is a long-standing behavior, which is very convenient with file
names.  It is documented in the node "Completion Exit" in the Emacs
manual.

We should not change this behavior.

> I think that Tab in step 2 should show the message and the list of
> possible completions at the same time.

That'd get in the way of selecting the "complete, but not unique"
candidate.  It is also a distraction.