From: Matt Tucker <tuck(a)whistlingfish.net>
Date: Sat, 30 Jun 2001 17:16:20 -0700
-- Jeff Mincy <jeff(a)delphioutpost.com> spake thusly:
minibuffer-complete-word is has a feature that I find annoying.
If you have the following files:
Then minibuffer-complete-word completes 'foo' then completes "foo
bar", with no indication that there were other files to complete.
Perhaps minibuffer-complete (which is bound to tab rather than space)
is more what you're looking for. For instance, with the aforementioned
files, I do:
yes. minibuffer-complete handles the above.
C-x f ~/f [space] [space] [space]
and XEmacs find "foo bar", as you said. This actually makes sense in
the context of the files that are there. When the second space is
typed, it matches the space in "foo bar" and therefore is inserted.
Then when the third space is typed after "foo ", the only thing left to
match is "foo bar".
Ok, I'll buy that, in this case, the space made sense, because it
could have been acting like self-insert-command and could have
inserted a literal space. But, you get the same behavior when
Here, the minibuffer-complete-word preferentially completes the
'bar-bar' and ignores 'bar.bar'.
However, if I do:
C-x f ~/f [TAB] [TAB]
XEmacs simply lists the possible completions. If you really don't like
minibuffer-complete-word at all, you could bind minibuffer-complete to
space and probably never worry about it again.
minibuffer-complete-word does handle this case better:
(Yes, I have a "ProgramFiles" link that points to "Program Files".
So, I could probably get the behavior I want by binding
minibuffer-complete to space (as you suggest) and then advising
minibuffer-complete to try a space (but only after a completions
buffer is being shown). Oh nevermind. tab is fine.