Re: Fixed bug in completing-read

[Luc Teirlinck <teirllm@dms.auburn.edu>]

I have fixed (in CVS) the bug I in `completing-read' which I reported
in my previous message.  Some packages may _rely_ on the bug.  This
concerns the initial position of point in an inserted default string
after entering the minibuffer.  In the (rare) case where the INITIAL
argument to `completing-read' is a cons of a string and an integer (as
opposed to just a string),`completing-read' used to put point one
positiom more to the right than `read-from-minibuffer', contradicting
its own documentation string.

This is now fixed.  There is no change in the (usual) case where
INITIAL is just a string: point appears at the end of the inserted
string.  In nearly all cases where initial is a cons, the purpose was
to make point appear at the _beginning_ of the inserted string.  To
get around the bug, many packages specified a position of 0 instead of
1.  This is *no problem*.  _Any_ integer 1 _or_ less puts point at the
beginning of the string.  The *only* time there is a problem is when
one tries to put point somewhere in the _middle_ of the inserted
string.  In that case, point will now appear one position more to the
_left_ than intended.  This can trivially be fixed by adding 1 to the
formula computing the position.  I fixed the one single example I knew
of.  However, the number of calls to `completing-read' is so huge and
many calls are so complex, that it is impossible to be certain that
there are no other cases.  So, if after entry to the minibuffer, on a
function that provides completion, point appears one position too far
to the left in the pre-inserted string, you know what the problem is
and it is trivial to fix.

Sincerely,

Luc.