Re: Fixed bug in completing-read

[Andreas Schwab <schwab@suse.de>]

Luc Teirlinck <teirllm@auburn.edu> writes:

> 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 includes read-file-name, when called by find-alternate-file.

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

No, it does not.  Compare the doc string of completing-read:

  If it is (STRING . POSITION), the initial input
  is STRING, but point is placed POSITION characters into the string.

with that of read-from-minibuffer:

  If INITIAL-CONTENTS is (STRING . POSITION), the initial input
  is STRING, but point is placed at position POSITION in the minibuffer.

"POSITION characters into string" == "at position POSITION in the
minibuffer" - 1.  String positions are zero-origin, buffer positions
are one-origin.

IMHO the behaviour of read-from-minibuffer is actually what should be
changed, because the Elisp manual describes it like this:

     Alternatively, INITIAL-CONTENTS can be a cons cell of the form
     `(STRING . POSITION)'.  This means to insert STRING in the
     minibuffer but put point POSITION characters from the beginning,
     rather than at the end.

which matches the (old) behaviour of completing-read, not
read-from-minibuffer.

Andreas.

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