* bug#51650: Autocomplete: first Tab should show *Completions* buffer @ 2021-11-07 4:27 Carlos Pita 2021-11-07 5:09 ` Carlos Pita 2021-11-07 7:28 ` Eli Zaretskii 0 siblings, 2 replies; 17+ messages in thread From: Carlos Pita @ 2021-11-07 4:27 UTC (permalink / raw) To: 51650 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#51650: Autocomplete: first Tab should show *Completions* buffer 2021-11-07 4:27 bug#51650: Autocomplete: first Tab should show *Completions* buffer Carlos Pita @ 2021-11-07 5:09 ` Carlos Pita 2021-11-07 7:29 ` Eli Zaretskii 2021-11-07 7:28 ` Eli Zaretskii 1 sibling, 1 reply; 17+ messages in thread From: Carlos Pita @ 2021-11-07 5:09 UTC (permalink / raw) To: 51650 > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#51650: Autocomplete: first Tab should show *Completions* buffer 2021-11-07 5:09 ` Carlos Pita @ 2021-11-07 7:29 ` Eli Zaretskii 2021-11-07 8:16 ` Carlos Pita 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2021-11-07 7:29 UTC (permalink / raw) To: Carlos Pita; +Cc: 51650 > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#51650: Autocomplete: first Tab should show *Completions* buffer 2021-11-07 7:29 ` Eli Zaretskii @ 2021-11-07 8:16 ` Carlos Pita 2021-11-07 8:24 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Carlos Pita @ 2021-11-07 8:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 51650 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#51650: Autocomplete: first Tab should show *Completions* buffer 2021-11-07 8:16 ` Carlos Pita @ 2021-11-07 8:24 ` Eli Zaretskii 2021-11-07 8:39 ` Carlos Pita 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2021-11-07 8:24 UTC (permalink / raw) To: Carlos Pita; +Cc: 51650 > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#51650: Autocomplete: first Tab should show *Completions* buffer 2021-11-07 8:24 ` Eli Zaretskii @ 2021-11-07 8:39 ` Carlos Pita 2021-11-07 10:28 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Carlos Pita @ 2021-11-07 8:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 51650 > > *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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#51650: Autocomplete: first Tab should show *Completions* buffer 2021-11-07 8:39 ` Carlos Pita @ 2021-11-07 10:28 ` Eli Zaretskii 2021-11-07 18:40 ` Carlos Pita 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2021-11-07 10:28 UTC (permalink / raw) To: Carlos Pita; +Cc: 51650 > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#51650: Autocomplete: first Tab should show *Completions* buffer 2021-11-07 10:28 ` Eli Zaretskii @ 2021-11-07 18:40 ` Carlos Pita 2021-11-07 19:00 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Carlos Pita @ 2021-11-07 18:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 51650 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#51650: Autocomplete: first Tab should show *Completions* buffer 2021-11-07 18:40 ` Carlos Pita @ 2021-11-07 19:00 ` Eli Zaretskii 2021-11-07 19:34 ` Carlos Pita 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2021-11-07 19:00 UTC (permalink / raw) To: Carlos Pita; +Cc: 51650 > 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? ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#51650: Autocomplete: first Tab should show *Completions* buffer 2021-11-07 19:00 ` Eli Zaretskii @ 2021-11-07 19:34 ` Carlos Pita 2021-11-07 19:55 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Carlos Pita @ 2021-11-07 19:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 51650 > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#51650: Autocomplete: first Tab should show *Completions* buffer 2021-11-07 19:34 ` Carlos Pita @ 2021-11-07 19:55 ` Eli Zaretskii 2021-11-07 20:27 ` Carlos Pita 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2021-11-07 19:55 UTC (permalink / raw) To: Carlos Pita; +Cc: 51650 > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#51650: Autocomplete: first Tab should show *Completions* buffer 2021-11-07 19:55 ` Eli Zaretskii @ 2021-11-07 20:27 ` Carlos Pita 2021-11-07 20:38 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Carlos Pita @ 2021-11-07 20:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 51650 > 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 :( ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#51650: Autocomplete: first Tab should show *Completions* buffer 2021-11-07 20:27 ` Carlos Pita @ 2021-11-07 20:38 ` Eli Zaretskii 2021-11-07 21:21 ` Lars Ingebrigtsen 2021-11-07 21:24 ` Carlos Pita 0 siblings, 2 replies; 17+ messages in thread From: Eli Zaretskii @ 2021-11-07 20:38 UTC (permalink / raw) To: Carlos Pita; +Cc: 51650 > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#51650: Autocomplete: first Tab should show *Completions* buffer 2021-11-07 20:38 ` Eli Zaretskii @ 2021-11-07 21:21 ` Lars Ingebrigtsen 2021-11-07 21:24 ` Carlos Pita 1 sibling, 0 replies; 17+ messages in thread From: Lars Ingebrigtsen @ 2021-11-07 21:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Carlos Pita, 51650 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#51650: Autocomplete: first Tab should show *Completions* buffer 2021-11-07 20:38 ` Eli Zaretskii 2021-11-07 21:21 ` Lars Ingebrigtsen @ 2021-11-07 21:24 ` Carlos Pita 2021-11-07 22:33 ` Stephen Berman 1 sibling, 1 reply; 17+ messages in thread From: Carlos Pita @ 2021-11-07 21:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 51650 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#51650: Autocomplete: first Tab should show *Completions* buffer 2021-11-07 21:24 ` Carlos Pita @ 2021-11-07 22:33 ` Stephen Berman 0 siblings, 0 replies; 17+ messages in thread From: Stephen Berman @ 2021-11-07 22:33 UTC (permalink / raw) To: Carlos Pita; +Cc: 51650 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#51650: Autocomplete: first Tab should show *Completions* buffer 2021-11-07 4:27 bug#51650: Autocomplete: first Tab should show *Completions* buffer Carlos Pita 2021-11-07 5:09 ` Carlos Pita @ 2021-11-07 7:28 ` Eli Zaretskii 1 sibling, 0 replies; 17+ messages in thread From: Eli Zaretskii @ 2021-11-07 7:28 UTC (permalink / raw) To: Carlos Pita; +Cc: 51650 > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2021-11-07 22:33 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-11-07 4:27 bug#51650: Autocomplete: first Tab should show *Completions* buffer Carlos Pita 2021-11-07 5:09 ` Carlos Pita 2021-11-07 7:29 ` Eli Zaretskii 2021-11-07 8:16 ` Carlos Pita 2021-11-07 8:24 ` Eli Zaretskii 2021-11-07 8:39 ` Carlos Pita 2021-11-07 10:28 ` Eli Zaretskii 2021-11-07 18:40 ` Carlos Pita 2021-11-07 19:00 ` Eli Zaretskii 2021-11-07 19:34 ` Carlos Pita 2021-11-07 19:55 ` Eli Zaretskii 2021-11-07 20:27 ` Carlos Pita 2021-11-07 20:38 ` Eli Zaretskii 2021-11-07 21:21 ` Lars Ingebrigtsen 2021-11-07 21:24 ` Carlos Pita 2021-11-07 22:33 ` Stephen Berman 2021-11-07 7:28 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.