bug#56380: 29.0.50; completing-read: INITIAL-INPUT arg

[Drew Adams]

> >> The docstring of `completing-read' says the argument INITIAL-INPUT
> >> is deprecated - yet there are over 30 nontrivial uses in Emacs'
> >> own Elisp sources.  So, although we currently don't want that this
> >> argument is used just to insert a default input, it's sometimes
> >> not possible to avoid using it.
> >
> >> +  for POSITION.)  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.  See
> >> +  `minibuffer-with-setup-hook' for a general method to prepare the
> >> +  minibuffer.
> >
> > It's an improvement on the original text, but this makes it sound like
> > inserting a common prefix is something callers are expected to do

No, it doesn't.  Or rather, why do you think so?

> > (But instead it's a super rare special case that virtually nobody
> > would actually do in practice.)

No, it isn't.  Or rather, why do you think so?

> > So I'd rather just remove that sentence about what you can
> > use INITIAL-INPUT for.

Uh, the point of the bug report is to document better
what INITIAL-INPUT does, in such a way that users can
understand what it's for.

> Or say that it should be used in rare cases like a common prefix or a
> cons cell for the history argument.  The docstring would be then more
> in line with the reference manual (the common prefix part has be to be
> added to the reference manual, but that is doable.)

I disagree that you should be claiming that its
use is or should be rare.  Just leave it alone,
please.

I disagree that it's only about a common prefix.

And I disagree that, even for just that particular
use case, the case is only about a common _prefix_.
And I disagree that it's even about _any_ common
bit of literal text.

What that use case is about is text that _can be
useful as initial input_.  That's all.

Text that users can edit easily, to put to use in
the current _completion context_ (which includes
use it by completing it).

With _prefix_ completion, yes, insertion of a prefix
is useful.  But even then, the most useful position
of point isn't necessarily _after_ that prefix.

With other kinds of completion, other "common" text
can be appropriate - a common substring, for example.

It's not that the text to be inserted is necessarily,
literally "common" to all or many of the candidates.
It can be that its _completion_, in the current
context, is common to some or all candidates.

And even that's not necessary.  It's only about some
usefulness of having the particular text inserted.

In general, that means usefulness in _editing_ it,
in the broadest sense -- doing <whatever> with it --
to some advantage.

The uses of `completing-read' are many - it contains
multitudes.

The text suggested is fine.  It doesn't go into all
of this.  It just says "for example", and the example
of common-prefix insertion is sufficient.

But if you can't see why/when/how what it does can
be useful then just say what the INIT arg _does_.

And make clear that it's _not_ about INIT being a
substitute for DEF.  The two are different and
independent, though they can also cooperate -- be
used together to advantage.

Please don't spread a prejudice that INIT is only
for some bizarre, "rare" use.  Plenty of optional
args in Emacs are _truly_ used only rarely, but
their doc rightfully doesn't try to steer users
away from using them.

There's nothing bad or dangerous about using an
INIT arg with `completing-read'.  It's high time
for Emacs to relax and get over it.