bug#994: 23.0.60; minibuffer completion should act on all minibuffer input

[Drew Adams]

emacs -Q
 
Given an existing file foo-bar.el, do `M-x foo-b RET', getting a new
buffer `foo-b'.
 
Then do `C-x C-v TAB'. There is no completion of `foo-b' to
`foo-bar.el', because (a) point is just after the directory name,
before `foo-b' (as it should be) and (b) completion now acts only
on the text before point.
 
This non-completion is a "feature" introduced in Emacs 22, the idea
being that only stuff to the left of point should be completed. To me,
this is a bug (misfeature), and this is a good example why.
 
Another example is when point is in the middle of some text that can
be completed, but it is completed differently from what the completion
of the whole minibuffer content would be. E.g. `M-x foo-toto', with
point after `foo' completes (I think) to `foo-bar.eltoto', which is
not helpful.
 
The user now needs to pay attention to where the cursor is. Previously
the entire minibuffer contents (after the prompt) were taken into
consideration for completion, just as they are for input (RET).

This boils down to forcing users to use `C-e' to complete the entire
input versus, in Emacs 20-21, users who wanted to complete only the
text before point using `C-k'. Seems like not a big deal, but in
practice I find it annoying. What's more, it is inconsistent with
the behavior of RET, which does act on the complete minibuffer input.
 
If Emacs Development won't remove this "feature", then please at least
provide a user option to obtain the previous, sane behavior.
 
Actually, in Emacs 23, things are worse yet. I have a file
`icicles-mcmd.el'. I type `M-x icicles-mcfoobar' and hit TAB with
point after the `mc'. It completes to `icicles-mcicles-foobar'.
Huh? No idea what logic is behind that, but perhaps it has to do
with the new automatic partical completion mode (which is also a
design mistake, IMO).  If instead point is at the end of the
input for `M-x icicles-mcfoobar', then it completes to
`icicles-mcfoobaricles'. Huh? Again, no idea what the logic is
behind this misbehavior.
 
IMO, the original (Emacs 20 or 21) behavior was superior: (1)
more efficient for editing (arguable, admittedly) and certainly
(2) much less confusing and more consistent. Please provide a
user option (or two, if necessary) so users can get back the
previous behavior.
 

In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-09-03 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include
-fno-crossjumping'