Re: C-x C-b and C-x C-f bugging about confirmation

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> In my experience typos are a lot more common than opening a
>> nonexistent file.
> It's a matter of usage patterns.  For myself, this change will probably
> be triggered hundreds or thousands of times for each mistake caught.

As explained to Eli, this is not a problem: you usually know that you're
creating a new file, so you'll just get used to hitting RET RET blindly
in those cases, as a matter of course.

>> (most commonly after a TAB completion which completed less than
>> expected)
> Hitting TAB after completion gives the message "[Sole completion]",
> which tells you that you have what you want.

I can assure you the situation I describe is real, I face it all
the time.  The situation you describe is when you hit TAB to check your
entry before hitting RET.  Maybe some people are patient enough to
do that.  Instead, I hit TAB to complete (not to check) and I hit RET
afterwards without even checking the result of TAB because I mistakenly
presume Emacs's completion can always read my mind.  I know I'm not
alone in this.
Not that it matters to this discussion anyway.

> But it has not been the default from the beginning, and it deviates from
> established rules about how the minibuffer behaves.  One expects RET,
> unlike TAB, to submit the minibuffer input.  (The only time RET doesn't
> do that is in an "error situation"---a minibuffer is expects an exact
> match and you haven't supplied that.)  Hence this double-RET behavior,
> with its cryptic "[Confirm]" prompt, is jarring.

It's a pretty minor difference.  As for [Confirm] being cryptic, we can
change it, of course, I don't care about the actual message, I just
reused the one used in the other similar case where RET needed to
complete the input: nobody complained about that one being cryptic, by
the way ;-)


        Stefan