C-x C-f, Tab (in)completion and visiting the wrong, new files

C-x C-f, Tab (in)completion and visiting the wrong, new files

[David Reitter]

Does this happen to you, too?

I've got several files in my directory:

foo.tex
foo.aux
foo.pdf
foo.1.tex
bar.txt


To open one, I do

C-x C-f
ba <TAB>
<RET>

and because I'm used to it, I do:

C-x C-f
fo <TAB>
<RET>

What happens then is that only "foo." is in the minibuffer, and a  
buffer visiting the non-existant file of that name is visited.  
Usually that means that I have to kill it and start again, navigating  
to the appropriate file. That is highly annoying.

Of course I could all blame it on myself and bind C-x C-f to `find- 
file-existing'.
But if the same happens to others as well, perhaps a more general  
change could make Emacs more convenient in this respect.

One option would be the following:

Whenever Tab is used to (partially) complete a file name (or even any  
other symbol), we assume that the user wants to input the name of an  
existing file (or element of the completion list). If the file name  
or symbol is incomplete due to an ambiguity, an immediately following  
RET just does `ding'. Otherwise, i.e. a further RET or some editing  
action in the buffer, just exists the minibuffer as before.

I think it is safe to assume the TAB means that a string existing in  
the completion table is to be entered, at least in the case of file  
name completion.

Re: C-x C-f, Tab (in)completion and visiting the wrong, new files

[Johan Bockgård]

David Reitter <david.reitter@gmail.com> writes:

> Usually that means that I have to kill it and start again

C-x C-v

> But if the same happens to others as well, perhaps a more general
> change could make Emacs more convenient in this respect.

find-file-confirm-nonexistent-file

-- 
Johan Bockgård

Re: C-x C-f, Tab (in)completion and visiting the wrong, new files

[David Reitter]

On 12 Aug 2007, at 11:40, Johan Bockgård wrote:

> David Reitter <david.reitter@gmail.com> writes:
>
>> Usually that means that I have to kill it and start again
>
> C-x C-v

Thanks, useful. The cursor is in an inconvenient place in the  
minibuffer, though, even though I believe it's intended that way.

>
>> But if the same happens to others as well, perhaps a more general
>> change could make Emacs more convenient in this respect.
>
> find-file-confirm-nonexistent-file

Could be done, but I don't think adding another confirmation step for  
new files (that are intended to be created) is as good as making the  
right guess when the user uses completion and confirms an incomplete  
(i.e. ambiguous) choice. This case may even be universal to all  
completion-based minibuffer inputs.

Re: C-x C-f, Tab (in)completion and visiting the wrong, new files

[Stefan Monnier]

>>> But if the same happens to others as well, perhaps a more general
>>> change could make Emacs more convenient in this respect.
>> find-file-confirm-nonexistent-file
> Could be done, but I don't think adding another confirmation step for new
> files (that are intended to be created) is as good as making the right
> guess when the user uses completion and confirms an incomplete
> (i.e. ambiguous) choice.

That's very interesting: I added the find-file-confirm-nonexistent-file
pretty for the exact reason you describe, and what you propose is
a refinement of it: to only do the "confirm" step if the previous command
was a completion command.  That makes a lot of sense: it may even be enabled
by default without provoking angry reactions, contrary to
find-file-confirm-nonexistent-file.  It could just be confirgured with a new
value `only-after-completion' for find-file-confirm-nonexistent-file.

> This case may even be universal to all completion-based minibuffer inputs.

Could be.


        Stefan

RE: C-x C-f, Tab (in)completion and visiting the wrong, new files

[Drew Adams]

> >>> But if the same happens to others as well, perhaps a more general
> >>> change could make Emacs more convenient in this respect.
> >> find-file-confirm-nonexistent-file
> > Could be done, but I don't think adding another confirmation
> step for new
> > files (that are intended to be created) is as good as making the right
> > guess when the user uses completion and confirms an incomplete
> > (i.e. ambiguous) choice.
>
> That's very interesting: I added the find-file-confirm-nonexistent-file
> pretty for the exact reason you describe, and what you propose is
> a refinement of it: to only do the "confirm" step if the previous command
> was a completion command.  That makes a lot of sense: it may even
> be enabled
> by default without provoking angry reactions, contrary to
> find-file-confirm-nonexistent-file.  It could just be confirgured
> with a new
> value `only-after-completion' for find-file-confirm-nonexistent-file.
>
> > This case may even be universal to all completion-based
> minibuffer inputs.
>
> Could be.

This proposal is essentially to require confirmation for lax completion.
With the `only-after-completion' value, confirmation would be required only
after TAB; any other non-nil value would always require confirmation for
input that doesn't match completely. Is that correct?

I have no objection to such an option to control the behavior, but I don't
think the default behavior should be changed.

RE: C-x C-f, Tab (in)completion and visiting the wrong, new files

[Drew Adams]

> I've got several files in my directory:
> foo.tex  foo.aux  foo.pdf  foo.1.tex  bar.txt
>
> I do: C-x C-f fo <TAB> <RET>
>
> What happens then is that only "foo." is in the minibuffer, and a
> buffer visiting the non-existant file of that name is visited.

I disagree with your proposal, David. Being able to use lax completion, for
file names and for other things, is very useful. I would not want to see
that behavior changed.

However, what I think should happen in the case you mention, and what
happens by default in Icicles, is that TAB immediately displays
*Completions*, which lets you know that completion is incomplete and lets
you see the matching candidate names of the existing files.

In Icicles, an option, `icicle-TAB-shows-candidates-flag', controls this.
Non-nil (the default value) means that TAB always shows the matching
candidates; nil means follow the standard Emacs behavior.

But in neither case (nil or non-nil) is lax completion foregone and strict
completion imposed. I would not want C-x C-f to assume that you want to
visit an existing file.

Re: C-x C-f, Tab (in)completion and visiting the wrong, new files

[David Reitter]

On 12 Aug 2007, at 19:22, Drew Adams wrote:

>> I've got several files in my directory:
>> foo.tex  foo.aux  foo.pdf  foo.1.tex  bar.txt
>>
>> I do: C-x C-f fo <TAB> <RET>
>>
>> What happens then is that only "foo." is in the minibuffer, and a
>> buffer visiting the non-existant file of that name is visited.
>
> I disagree with your proposal, David. Being able to use lax  
> completion, for
> file names and for other things, is very useful. I would not want  
> to see
> that behavior changed.

My proposal was not to change completion. My proposal was to not  
accept a RET after an incomplete completion. (But a RET RET after an  
incomplete completion would do exactly what the RET does.)

Where do you think is incomplete completion and entering of the  
incomplete string useful?

> However, what I think should happen in the case you mention, and what
> happens by default in Icicles, is that TAB immediately displays
> *Completions*, which lets you know that completion is incomplete  
> and lets
> you see the matching candidate names of the existing files.

I like the current behavior - simply because you know what files are  
there (or what you want) anyways. No need to see *Completions*.

> But in neither case (nil or non-nil) is lax completion foregone and  
> strict
> completion imposed. I would not want C-x C-f to assume that you  
> want to
> visit an existing file.

Again, that's not what I said. I said that only if completion is  
used, we assume (temporarily) that an existing file is to be visited.  
If the user completes the file name manually, then that is fine and  
it can be a new file.

RE: C-x C-f, Tab (in)completion and visiting the wrong, new files

[Drew Adams]

> My proposal was not to change completion. My proposal was to not
> accept a RET after an incomplete completion.

That's changing completion.

> (But a RET RET after an
> incomplete completion would do exactly what the RET does.)
>
> Where do you think is incomplete completion and entering of the
> incomplete string useful?

The case you gave is good enough: creating a new file buffer, `foo.' (or any
other partial prefix match).

> > However, what I think should happen in the case you mention, and what
> > happens by default in Icicles, is that TAB immediately displays
> > *Completions*, which lets you know that completion is incomplete
> > and lets you see the matching candidate names of the existing files.
>
> I like the current behavior - simply because you know what files are
> there (or what you want) anyways. No need to see *Completions*.

How do you know "what files are there"? How do you know which file names
match? How do you know that your input is an incomplete match against
multiple file names?

It sounds, from what you said, like you didn't sense that you had only a
partial match and that RET would create a new file buffer. That is, it
sounds like you felt that you already had a complete match and hitting RET
would open an existing file whose name matched.

If *Completions* were shown, you would not be mistaken in that way, IMO. You
would have feedback that completion was incomplete with multiple matches.

Alternative (or additional) feedback could be to show a minibuffer message
to let you know this status.

> I said that only if completion is
> used, we assume (temporarily) that an existing file is to be visited.
> If the user completes the file name manually, then that is fine and
> it can be a new file.

I too was speaking of when TAB completion is used, not of typing the
complete name manually.

You want TAB RET to go `ding' and TAB RET (ding) RET to do what TAB RET does
now, whenever there are multiple matches and there is no complete match -
right? And you propose that behavior for not only a file name but "any other
symbol" - right?

I disagree. The current behavior is good, but perhaps it would be an
improvement to provide some feedback that would let you know the state you
are in, so you don't hit RET until you get a match for an existing file, if
that's what you want. IMO, RET should cause input to be entered, it
shouldn't just complete or go `ding'.

Re: C-x C-f, Tab (in)completion and visiting the wrong, new files

[Stefan Monnier]

> However, what I think should happen in the case you mention, and what
> happens by default in Icicles, is that TAB immediately displays
> *Completions*, which lets you know that completion is incomplete and lets
> you see the matching candidate names of the existing files.

That doesn't help.  The "TAB RET" sequence is hit much too quickly, as a sort
of atomic entity.  There's no time for a user like me (and apparently David)
to adjust things after the TAB but before the RET.


        Stefan

RE: C-x C-f, Tab (in)completion and visiting the wrong, new files

[Drew Adams]

> > However, what I think should happen in the case you mention, and what
> > happens by default in Icicles, is that TAB immediately displays
> > *Completions*, which lets you know that completion is
> > incomplete and lets you see the matching candidate names of the
> > existing files.
>
> That doesn't help.  The "TAB RET" sequence is hit much too
> quickly, as a sort of atomic entity.  There's no time for a
> user like me (and apparently David) to adjust things after
> the TAB but before the RET.

If you have a habit of hitting TAB RET, then you are, in effect, expecting
TAB to complete to a complete match, so that RET will open the existing file
whose name matches. With that expectation, incomplete matches throw you off.
In that case, you want TAB to complete only against existing files, no? Then
why not bind `file-file-existing'? That's what it's for.

Re: C-x C-f, Tab (in)completion and visiting the wrong, new files

[David Reitter]

On 12 Aug 2007, at 21:12, Drew Adams wrote:

> If you have a habit of hitting TAB RET, then you are, in effect,  
> expecting
> TAB to complete to a complete match, so that RET will open the  
> existing file
> whose name matches. With that expectation, incomplete matches throw  
> you off.

Absolutely.

> In that case, you want TAB to complete only against existing files,  
> no? Then
> why not bind `file-file-existing'? That's what it's for.

I think I suggested this originally. However, this would prevent  
users from creating new buffers as intended, or it would require us  
to come up with a new (and short) key combination.

I also thought that the input errors with the incomplete matches may  
be part of a common pattern that does not just apply to file names.  
In other completion cases where there is an ambiguity (e.g., M-x tex  
RET), the input is not accepted, and if there is no ambiguity, the  
input is autocompleted (e.g., M-x text RET).

RE: C-x C-f, Tab (in)completion and visiting the wrong, new files

[Drew Adams]

> > In that case, you want TAB to complete only against existing files,
> > no? Then why not bind `file-file-existing'? That's what it's for.
>
> I think I suggested this originally. However, this would prevent
> users from creating new buffers as intended,

C-x b has lax completion.

It does not, however, follow `auto-mode-alist'. But see the recent
discussion about adding something similar for buffer names
(`buffer-auto-mode-alist').

> or it would require us
> to come up with a new (and short) key combination.

Just rebind C-x C-f, if that's your preference.

> I also thought that the input errors with the incomplete matches may
> be part of a common pattern that does not just apply to file names.
> In other completion cases where there is an ambiguity (e.g., M-x tex
> RET), the input is not accepted, and if there is no ambiguity, the
> input is autocompleted (e.g., M-x text RET).

Those are cases of strict completion, where the completed input must match a
candidate. They are equivalent to passing a non-nil REQUIRE-MATCH arg to
`completing-read'. `find-file' provides lax completion, and
`find-file-existing' provides strict completion - both are available.

RE: C-x C-f, Tab (in)completion and visiting the wrong, new files

[Davis Herring]

> If you have a habit of hitting TAB RET, then you are, in effect, expecting
> TAB to complete to a complete match, so that RET will open the existing
> file whose name matches. With that expectation, incomplete matches throw
> you off.  In that case, you want TAB to complete only against existing
> files, no?  Then why not bind `file-file-existing'? That's what it's for.

`find-file-existing' doesn't actually affect TAB; it affects RET.  So it's
true that it has a desirable effect on the dyad TAB RET, but it affects
all other RETs too.  By having special consideration for RET only after
TAB, we can change that dyad only.  That said, I have no strong opinion
here; I just want the true distinctions between options recognized.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

RE: C-x C-f, Tab (in)completion and visiting the wrong, new files

[Drew Adams]

> > If you have a habit of hitting TAB RET, then you are, in
> > effect, expecting TAB to complete to a complete match, so
> > that RET will open the existing file whose name matches.
> > With that expectation, incomplete matches throw you off.
> > In that case, you want TAB to complete only against existing
> > files, no?  Then why not bind `file-file-existing'? That's what
> > it's for.
>
> `find-file-existing' doesn't actually affect TAB; it affects RET.  So it's
> true that it has a desirable effect on the dyad TAB RET, but it affects
> all other RETs too.  By having special consideration for RET only after
> TAB, we can change that dyad only.  That said, I have no strong opinion
> here; I just want the true distinctions between options recognized.

A useful clarification, and it speaks to David's point that he wants
confirmation only after completion, not in general. That is, he wants to be
able to open a new file with `C-x C-f', but not using TAB RET.

`buffer-auto-mode-alist' might respond to this need (use `C-x b' to create a
buffer for a file with a new name, and otherwise bind `C-x C-f' to
`find-file-existing'), but it would mean that users would need to customize
this.

Stefan's suggestion to allow an `only-after-completion' value for
`find-file-confirm-nonexistent' makes the most sense. I think that would
make everyone happy. (The default value of `find-file-confirm-nonexistent'
should remain, nil, however, IMO.)

Re: C-x C-f, Tab (in)completion and visiting the wrong, new files

[David Reitter]

On 13 Aug 2007, at 18:42, Drew Adams wrote:

> Stefan's suggestion to allow an `only-after-completion' value for
> `find-file-confirm-nonexistent' makes the most sense. I think that  
> would
> make everyone happy. (The default value of `find-file-confirm- 
> nonexistent'
> should remain, nil, however, IMO.)

Yes, Stefan's suggestion sounds doable. However, I would actually  
prefer for it to be the default, as there I see benefits especially  
for new users and little problems for others.

Secondly, I don't think we should go through the full confirmation  
dialog. Instead, just a "ding" sound should be enough, and a second  
RET would then act as confirmation.

Is this really a special case for file name completion, and really  
only for `find-file'?
Does it not apply to all kinds of completion?

RE: C-x C-f, Tab (in)completion and visiting the wrong, new files

[Drew Adams]

> > Stefan's suggestion to allow an `only-after-completion' value for
> > `find-file-confirm-nonexistent' makes the most sense. I think that
> > would make everyone happy. (The default value of
> > `find-file-confirm-nonexistent' should remain, nil, however, IMO.)
>
> Yes, Stefan's suggestion sounds doable. However, I would actually
> prefer for it to be the default, as there I see benefits especially
> for new users and little problems for others.

We disagree about the default value. WDOT?

> Secondly, I don't think we should go through the full confirmation
> dialog. Instead, just a "ding" sound should be enough, and a second
> RET would then act as confirmation.

No special opinion on that, but what you say sounds reasonable to me.

> Is this really a special case for file name completion, and really
> only for `find-file'? Does it not apply to all kinds of completion?

The same considerations apply, probably, but it's not clear that a given
user would necessarily want the same behavior for all lax completion. Dunno
if it might be good to have two such options, one for `read-file-name' and
one for `completing-read'.

BTW, I assume (and hope) that this `only-after-completion' behavior would
apply only for TAB RET, not for TAB followed by some editing followed by
RET. That is, it is not just "after completion"; it is "immediately after
completion". It's important to be able to use completion to get a value that
you then edit and enter with RET. In such a case, it would not make sense
for `only-after-completion' to `ding' and require a second RET.

Re: C-x C-f, Tab (in)completion and visiting the wrong, new files

[Stefan Monnier]

>> Stefan's suggestion to allow an `only-after-completion' value for
>> `find-file-confirm-nonexistent' makes the most sense. I think that  would
>> make everyone happy. (The default value of `find-file-confirm-
>> nonexistent'
>> should remain, nil, however, IMO.)

> Yes, Stefan's suggestion sounds doable.  However, I would actually prefer
> for it to be the default, as there I see benefits especially for new users
> and little problems for others.

Agreed.

> Secondly, I don't think we should go through the full confirmation
> dialog.

find-file-confirm-nonexistent doesn't use a "confirmation dialog", it just
puts a "[Confirm]" text in the minibuffer and rejects the RET (so you just
need to hit RET a second time).

> Is this really a special case for file name completion, and really only
> for find-file'?  Does it not apply to all kinds of completion?

It could, but I can't remember bumping into this TAB RET problem in other
circumstances, so we could definitely experiment with it, but I think the
priority should be to implement for the find-file case.  It's also more
likely to be accepted as a default if it's more limited in scope.


        Stefan

Re: C-x C-f, Tab (in)completion and visiting the wrong, new files

[David Reitter]

On 13 Aug 2007, at 19:15, Stefan Monnier wrote:

> find-file-confirm-nonexistent doesn't use a "confirmation dialog",  
> it just
> puts a "[Confirm]" text in the minibuffer and rejects the RET (so  
> you just
> need to hit RET a second time).

Is that a variable to set (I don't have it), or how can I try this out?

I presume the [Confirm] text appears next to the entered file name  
and doesn't replace it?
That would be good.

Drew Adams wrote:

> The same considerations apply, probably, but it's not clear that a  
> given
> user would necessarily want the same behavior for all lax  
> completion. Dunno
> if it might be good to have two such options, one for `read-file- 
> name' and
> one for `completing-read'.

The reason why I'm pushing for this is that I find it reasonable to  
have one behavior for as many cases as possible. Special cases are  
usually confusing.

To experiment with this, we could use the two keymaps that exist,  
e.g. `minibuffer-local-filename-completion-map', where we could  
rebind RET to something that checks whether the previous command was  
a completion command.

> BTW, I assume (and hope) that this `only-after-completion' behavior  
> would
> apply only for TAB RET, not for TAB followed by some editing  
> followed by
> RET. That is, it is not just "after completion"; it is "immediately  
> after
> completion".

Correct.

Re: C-x C-f, Tab (in)completion and visiting the wrong, new files

[Stefan Monnier]

>> find-file-confirm-nonexistent doesn't use a "confirmation dialog",
> Is that a variable to set (I don't have it), or how can I try this out?

It's actually find-file-confirm-nonexistent-file.


        Stefan

RE: C-x C-f, Tab (in)completion and visiting the wrong, new files

[Drew Adams]

> >> find-file-confirm-nonexistent doesn't use a "confirmation dialog",
> > Is that a variable to set (I don't have it), or how can I try this out?
>
> It's actually find-file-confirm-nonexistent-file.

It's not in the released 22.1, but you can find it in a recent version of
files.el -
http://cvs.savannah.gnu.org/viewvc/emacs/emacs/lisp/files.el?view=log.