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

["Drew Adams" <drew.adams@oracle.com>]

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