Re: Fixed bug in completing-read

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

Richard Stallman wrote:

   Since this is a rather obscure feature, not used in too many places,
   we should make the decision based on what is clean, not based on
   compatibility with this or that.  Since these positions go with
   strings, they should be zero-origin.

I have reverted my changes in `Fcompleting_read', as well as the
related change in ffap.el.  The entire treatment of conses as values
for INITIAL is back to where it was before my changes, except that a
few more functions can handle such values.

I do not know whether your remark above only applies to
`completing-read' (in which case it is completely taken care of) or
also to `read-from-minibuffer' and friends.  In the latter case, I
would have only one single objection, but a big one.  That is the
amount of work involved in adapting existing code.  The feature is
used more often than you seem to believe.  I already had my
reservations about changing things the other way around, but this way
things are a _lot_ worse.  (I took a look at it.)

The very existence of INITIAL is unclean (it competes with DEFAULT and
provides an inconsistent user interface) and it only exists for
historical compatibility.  Hence, I propose to just document the
inconsistency and say that the entire argument, inconsistencies and
all, only exists for historical compatibility anyway.  Just one more
reason to use DEFAULT instead.

A semi-obsolete argument is not worth tons of work.  Existing code
seems to use the argument based on the inconsistency, so no problem
there.  New code should not use it, so no problem there either.

Sincerely,

Luc.