Re: Two problems of completion

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

> Currently SPC is bound to minibuffer-complete-word in minibuffer.
> With partial completion facilities implemented for minibuffer, I don't
> know whether it is still right to bind SPC to this command, but if so
> I find two problems.

> 1. Special case: the string before completion is the empty string "".

> In this case, completion--try-word-completion will see a completion
> available, i.e. ("" . 0), and then try firstly completing with " " (""
> + " ") and then "-" ("" + "-").  Partial completion often (e.g. in a
> command execution context, i.e. typing M-x then typing SPC) returns a
> result of ("-" . 0), make a completion available.

> I think when the user press SPC directly in such a case, it means that
> the user wants to see a list of available completions, instead of
> wanting a partially completed word.  So this case might need special
> handling.

Yes, it looks like a poor situation indeed.  Then again pressing SPC at
an empty minibuffer might be because you do want to insert a leading SPC
(to enter the name of a hidden buffer, for example).

I see that `partial-completion-mode' suffers from the same problem.

Hmm... not sure what to do.


> 2. Minibuffer content rewriting.

> The current minibuffer content rewriting facility in
> completion--do-completion seems not for partial completion.

I've just fixed a bug w.r.t computation of the new position of point
after completion.   I believe that's what you were experiencing,


        Stefan