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

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'
 

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

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

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

Counter example: I visit a file, then want to visit a new file with the
same name but in a different directory.  Type C-x C-f <left> <down>,
edit the directory before point and type TAB.  I expect to get the
directory part properly completed although the file does not exist.
Completion is inherently context dependent.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Drew Adams]

> From: Drew Adams Sent: Wednesday, September 17, 2008 1:57 PM
> emacs -Q
>  
> Given an existing file foo-bar.el, do `M-x foo-b RET', getting a new
> buffer `foo-b'.

Sorry, I meant `C-x C-f', not `M-x'.

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

[Drew Adams]

> From: Andreas Schwab Sent: Wednesday, September 17, 2008 2:33 PM
> "Drew Adams" <drew.adams@oracle.com> writes:
> > 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.
> 
> Counter example: I visit a file, then want to visit a new 
> file with the
> same name but in a different directory.  Type C-x C-f <left> <down>,
> edit the directory before point and type TAB.  I expect to get the
> directory part properly completed although the file does not exist.
> Completion is inherently context dependent.

Sure there are counter examples, and that's a good one. And different users have
different preferences wrt which examples (behaviors) are most important to them.

All I'm asking for is a way to return to the previous behavior, which I prefer.
Call it a bug or a feature, as you like. I would like a user option to be able
to choose the alternative behavior.

And the other part of the bug report, which is Emacs 23-specific (related to
automatic partial completion?) is something else again. There too there should
be an easy and obvious way to turn off such smart/silly (your choice) behavior.

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

[Stefan Monnier]

> 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.
 
Can you provide a recipe to reproduce the above two behaviors?


        Stefan

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

[Drew Adams]

> > 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.
>  
> Can you provide a recipe to reproduce the above two behaviors?

Exactly the recipe I gave above (with the correction I sent later
that I meant `C-x C-f', not `M-x'):

emacs -Q
Create a file icicles-mcmd.el in directory /my/dir.

C-x C-f
Find file: /my/dir/icicles-mcfoobar TAB
                             ^
                             +-- point here
gives:

Find file: /my/dir/icicles-mcicles-foobar

And:

Find file: /my/dir/icicles-mcfoobar TAB
                                   ^
                                   +-- point here
gives:

Find file: /my/dir/icicles-mcicles-foobaricles

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'