bug#65348: RE: [External] : bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Drew Adams]

> > > I suggest that the capability of prefilling the minibuffer be
> > > reintroduced for the new scheme as well.  Because from what
> > > I see, the deprecated parts include a feature that will be
> > > automatically discarded under the new scheme.
> >
> > I missed that memo completely!  What's the new scheme?
> 
> The new scheme of using history which automatically discarded
> the capability of prefilling the minibuffer before cycling can
> start.

I don't understand.  There's a proposal to NOT
SUPPORT INITIAL at all anymore?  I definitely
oppose that.  What is hoped to be _gained_, by
taking away this feature?

> > What is expected to be automatically discarded?  Where
> > is the presentation/discussion of such a change?  Is
> > it this bug thread?  (Why would it be in a bug thread?)
> 
> As INITIAL is obsolete, the capability of prefilling the
> minibuffer entry would be missing.

That's ridiculous.  Why would anyone want to remove
that feature?  Have we gone from (1) some deciding
that INITIAL isn't as good as DEFAULT (even though
they have different behaviors and thus different
uses) to (2) some deciding that INITIAL shouldn't
be supported at all?

Was there some problem discovered with allowing
users to use INITIAL if/when they really want to?
I don't think so.

> > I hope we're not changing the longstanding arg list of
> > `completing-read' (except perhaps to add more args,
> > which might be debatable but excusable).
> 
> It is a problem.  We have been very happy adding more args for
> new features, without taking serious consideration the resulting
> confusion between old schemes and new schemes, resulting in numerous
> recommendations.  The less recommendations on how to use a function
> the better things will be to work with.

Sorry to say it, but that's just nonsense.  If
Someone (TM) finds it too complicated to deal
with complex recommendations then don't recommend
anything about INITIAL or whatever.  That's not a
reason to remove it - just because some people
might not ever use it.  If your guidance seems to
be ending up to complicated then maybe it's a bit
misguided.  Maybe start over and don't advise so
much.  WHAT the CODE does is what matters, and
that's clear - clearer than any supposedly derived
description of what you should use when.

`completing-read' _is_ complex, and it _does_ have
many different use patterns.  Should we remove
some of the different values we allow for argument
COMPLETIONS, because that would make describing
the function easier or simpler to understand?

That way lies madness.  If Someone wants a
simplified, dumbed-down `completing-read' then
they can create another function that does what
they want.  But leave the original alone. There's
no need to go deprecating and removing features
that others put to what they consider to be good
use.

I don't know who's requesting such changes,
misguidedly thinking they're improving things,
so I write "Someone".  I mean "they", whoever
they might be.

> When deep changes happen, I prefer to keep the old as is,
> and make a new function for significant changes that affect
> the old functionality.

Make a new function that _doesn't_ affect the
old functionality.  That's the point.  If
Someone wants a new/different behavior then
they can code it up and give it a name - a
new name.  It shouldn't affect good old
`completing-read' at all.

> It does not happen regularly that new features are accessed in ways that
> maintain clarity and avoids unnecessary complexity.

And?  Not sure I follow your point there.

> > Let's please keep this function backward-compatible.
> > If you want something different, please add it as a
> > separate function.
> 
> That's the whole point, and we should follow that route
> as an important strategy for maintainers.

I think maybe you're agreeing with me, or I with
you?

Regardless of who's pushing it, if Someone wants
to get rid of INITIAL then I object.  I objected
when the doc was changed to say it's ill-advised
etc.  I don't have a problem with calling out the
special case that's mentioned wrt placement of
point.  I do object to the doc saying that that's
the ONLY case where anyone should ever use INITIAL.

Let's please stop with the "shoulds" altogether,
unless they're backed up with clear reasons.
Otherwise that's just "I don't like" whatever -
beards or piano or watermelon or...

And there never was any need/reason for such a
restriction/admonishment against INITIAL.  It's
just overeager-beaver control syndrome, IMO.
There was never anything to warn users away from
or protect them from.  Using INITIAL won't get
anyone in trouble.  Whether it's the best tool
for the job depends on what the job is and what
your taste is.

Whether Someone thinks that stylistically it's
always bad to use INITIAL is, IMO, irrelevant.
Someone is just plain wrong.  The devil, when it
comes to what's useful in any given case, is in
the details of the context of calling
`completing-read', and in the users of that code.

Someone should be a little less presumptuous, and
just let it be.  Circulez - il n'y a rien a voir!