Re: Fixed bug in completing-read

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

Andreas Schwab wrote:

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

To me, the English phrase "POSITION characters into string" is
equivalent with the technical Lisp phrase "at (zero-indexed) position
POSITION - 1 in string".  I could be wrong and, clearly, you
understand it differently.  The one thing this means for certain is
that things should be reformulated more unambiguously, in all involved
places, which I will do.

   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.

Again, to me, the English phrase "POSITION characters from the
beginning" agrees with the behavior of read-from-minibuffer and
contradicts the old behavior of completing-read.  Again, I could be
wrong.  Same remark as above.

Anyway, terminology aside, we have three choices:

1. Adapt `completing-read' to `read-from-minibuffer'.  This is done in
   current CVS.

2. Adapt `read-from-minibuffer' to `completing-read', as you propose.

3. Keep the pre-yesterday behavior and clearly document the difference
   in behavior.

When I first brought this up, I offered to implement either (1) or
(3).  Richard decided on (1).  I could easily implement (2) too, if it
would be decided that this would be better.  In terms of "writing the
code", it just means adding or erasing a + 1 or -1, completely
trivial, and we do not need to undo the moving of the involved code
into read_minibuf, which was necessary, because certain functions
claimed they could handle conses for INITIAL, whereas they could not
(they can now).

Note that (2) would break existing code, just like (1) does, and it
would be equally difficult to find all that code.  (3) does not have
that problem, but the inconsistency is ugly and confusing.

If we decide to stay with (1), I would adapt `read-file-name'.

Maybe it might be good to move the duplicate (but currently, in as far
as I know, consistent) treatment of the HISTORY argument from
`read-from-minibuffer' and `completing-read' into `read_minibuf', as
was done for INITIAl, just to prevent future inconsistencies from
developing. I could easily do so, if desired.

Sincerely,

Luc.