RE: completion problem with read-file-name

[Drew Adams]

> > >     ** The completion commands TAB, SPC and ? in the minibuffer apply
> > >     only to the text before point.  If there is text in the buffer
> > >     after point, it remains unchanged.
> >
> > Thanks for the info. Still seems like retrogression to me.
>
> You never explained why you thought it was a retrogression.

Sure I did:

> In previous versions of Emacs, completion used the entire minibuffer
> input, not just the part before the cursor.  I don't know if this
> change is considered a feature, but it seems like a bug to me.  To me,
> the old behavior makes sense: all of your input is tested by
> completion, not just the part before point.

This is just my opinion, of course, but I think the behavior in all previous
Emacs releases is preferable. Just as hitting `RET' takes the entire
minibuffer input into account, no matter the cursor position, so has this
always been true for `TAB' as well. To me, that makes sense. I don't find it
helpful for Emacs to complete qqq.el to qq-xxx-q.elq.el if the cursor is on
the third q. Such a completion is useless, and requires me to hit C-k.

I'm not claiming that everyone (or even anyone) else will agree with me, but
I find the previous behavior better.

I'm not that concerned by this change, personally, as I always use Icicles,
whose prefix completion is like the previous Emacs behavior, and which also
allows regexp/substring completion. I nevertheless consider this change to
be in the wrong direction for Emacs.

Here, again, is the part of the bug report to reproduce what I consider to
be bad behavior:

> emacs -Q
>
> Create files qqq.el and qq-xxx-q.el in the same directory. Visit Dired
> there.
>
> C-x C-f qqq.el TAB, then C-b C-b C-b C-b, then type -xxx TAB.
>
> The minibuffer input is completed to qq-xxx-q.elq.el (with the cursor
> on the last `q').