RE: [External] : Doc of deprecated INITIAL-INPUT arg of completing-read

[Drew Adams]

> > All that's needed is to make clear that INIT
> > isn't intended as a _substitute_ for a default
> > value - and vice versa.  That's really the point
> > (IMO).  The use cases of INIT are different from
> > those of DEF.  That's what should be made clear.
> > Then leave it up to coders to use each as they
> > see fit.
> 
> Mostly agreed.  But as I said, I only intend to describe the current
> coding recommendations better, and these don't regard INITIAL-INPUT and
> DEF as equivalent alternatives.
> 
> As a compromise, here is a reworded version:

  Don't use this argument to insert a default--pass
  nil for INITIAL-INPUT and supply the default value DEF except in
  cases like inserting a prefix common to all completions or an
  initial part of a file name.  The user can yank the default value
  into the minibuffer easily using M-n.

Mostly agreed. ;-)

Suggestion:

  Don't use this argument to insert a default value --
  use DEF for that.  You can use INITIAL-INPUT, for
  example, to insert a prefix common to all completion
  candidates.

1. "default value" instead of "default".
2. INIT is independent of DEF.  Don't say not to use it
   except for XYZ.  Instead, just say not to use it as
   a substitute for providing a default value.  That was
   my point.
3. Give the example of inserting a common prefix as just
   that: an example.  Don't suggest it's the only use case.
4. A filename prefix is just a prefix, no?
5. The doc already says that users can yank DEF with `M-n'.
   (Or if it doesn't then that should be said where DEF
   is described, not where INIT is described.
___

(The "prefix" insertion case is only particularly
relevant when `completion-styles' favors prefix completion.
With other styles the common text you insert isn't
necessarily a prefix.)