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

[Christopher Dimech <dimech@gmx.com>]

> Sent: Monday, August 21, 2023 at 5:23 PM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Michael Heerdegen" <michael_heerdegen@web.de>, "eliz@gnu.org" <eliz@gnu.org>, "heimeborgia@protonmail.com" <heimeborgia@protonmail.com>, "65348@debbugs.gnu.org" <65348@debbugs.gnu.org>
> Subject: bug#65348: RE: [External] : bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively
>
> > > > 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?

It all depends whether INITIAL-INPUT would be deprecated.



> > > 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.

This really has to be cleared out.

> > > 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.

I agree

> 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.

The changes to completing-read needs clarification.

> `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 agree.

> 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.

Absolutely right.

> > 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.

Serious focus on clarity is needed, rather than simply go on with
changes.

> > > 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?

I am agreeing.

> 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 concur with your objection.

> 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.

Using INITIAL does not cause problems.  Contrarily it provides
a clear way to prefill the minibuffer.

Avoiding things like so

(minibuffer-with-setup-hook (lambda () (insert "BBB"))
  (completing-read "Input: " (list "AAA" "BBB" "CCC")))


> 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!
>