bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Have seen that when I include INITIAL-INPUT that happens to be the first entry 
in the collection COLLECJ, the entry "barwedge" is displayed twice consecutively.

But such situation does not happen when selecting a different entry from collection.

(let ( (collecj '("barwedge"  "boxdot"  "boxminus"  "boxplus"
                  "boxtimes"  "Cap"  "centerdot" "circledast"

  (completing-read "Grapheme: " collecj nil t "barwedge")

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Eli Zaretskii]

> Date: Thu, 17 Aug 2023 00:47:28 +0000
> From:  Heime via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 
> Have seen that when I include INITIAL-INPUT that happens to be the first entry 
> in the collection COLLECJ, the entry "barwedge" is displayed twice consecutively.
> 
> But such situation does not happen when selecting a different entry from collection.
> 
> (let ( (collecj '("barwedge"  "boxdot"  "boxminus"  "boxplus"
>                   "boxtimes"  "Cap"  "centerdot" "circledast"
> 
>   (completing-read "Grapheme: " collecj nil t "barwedge")

Sorry, I don't understand what you are saying.  What do you mean by
"is displayed twice consecutively"?  I guess some details are missing
from your report to make it complete and self-explanatory?

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sent with Proton Mail secure email.

------- Original Message -------
On Thursday, August 17th, 2023 at 5:49 PM, Eli Zaretskii <eliz@gnu.org> wrote:


> > Date: Thu, 17 Aug 2023 00:47:28 +0000
> > From: Heime via "Bug reports for GNU Emacs,
> > the Swiss army knife of text editors" bug-gnu-emacs@gnu.org
> > 
> > Have seen that when I include INITIAL-INPUT that happens to be the first entry
> > in the collection COLLECJ, the entry "barwedge" is displayed twice consecutively.
> > 
> > But such situation does not happen when selecting a different entry from collection.
> > 
> > (let ( (collecj '("barwedge" "boxdot" "boxminus" "boxplus"
> > "boxtimes" "Cap" "centerdot" "circledast"
> > 
> > (completing-read "Grapheme: " collecj nil t "barwedge")
> 
> 
> Sorry, I don't understand what you are saying. What do you mean by
> "is displayed twice consecutively"? I guess some details are missing
> from your report to make it complete and self-explanatory?

Consider the function defined by

(defun bigops (grafm seltr)
  (interactive
    (let ( (collecj '("boxplus" "boxtimes" "Cap" "centerdot" "circledast")) )
      (completing-read "Grapheme: " collecj nil t "boxplus")))

The user would see "boxplus", then the following element shows "boxplus"
consecutively again.  Could you consider the capability that when one uses
REQUIRE-MATCH, the function finds the entry for INITIAL-INPUT so that the 
next thing that gets shown after that starts from the one following the 
match in COLLECTION.  Otherwise, one is forced to put the INITIAL-INPUT
entry at the end of COLLECTION.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Eli Zaretskii]

> Date: Thu, 17 Aug 2023 06:05:06 +0000
> From: Heime <heimeborgia@protonmail.com>
> Cc: 65348@debbugs.gnu.org
> 
> > Sorry, I don't understand what you are saying. What do you mean by
> > "is displayed twice consecutively"? I guess some details are missing
> > from your report to make it complete and self-explanatory?
> 
> Consider the function defined by
> 
> (defun bigops (grafm seltr)
>   (interactive
>     (let ( (collecj '("boxplus" "boxtimes" "Cap" "centerdot" "circledast")) )
>       (completing-read "Grapheme: " collecj nil t "boxplus")))
> 
> The user would see "boxplus", then the following element shows "boxplus"
> consecutively again.  Could you consider the capability that when one uses
> REQUIRE-MATCH, the function finds the entry for INITIAL-INPUT so that the 
> next thing that gets shown after that starts from the one following the 
> match in COLLECTION.  Otherwise, one is forced to put the INITIAL-INPUT
> entry at the end of COLLECTION.

Sorry, I still don't understand: what are "the following element" and
"the next thing that gets shown"?  Shown how?  What causes them to be
shown?

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sent with Proton Mail secure email.

------- Original Message -------
On Thursday, August 17th, 2023 at 7:20 PM, Eli Zaretskii <eliz@gnu.org> wrote:


> > Date: Thu, 17 Aug 2023 06:05:06 +0000
> > From: Heime heimeborgia@protonmail.com
> > Cc: 65348@debbugs.gnu.org
> > 
> > > Sorry, I don't understand what you are saying. What do you mean by
> > > "is displayed twice consecutively"? I guess some details are missing
> > > from your report to make it complete and self-explanatory?
> > 
> > Consider the function defined by
> > 
> > (defun bigops (grafm seltr)
> > (interactive
> > (let ( (collecj '("boxplus" "boxtimes" "Cap" "centerdot" "circledast")) )
> > (completing-read "Grapheme: " collecj nil t "boxplus")))
> > 
> > The user would see "boxplus", then the following element shows "boxplus"
> > consecutively again. Could you consider the capability that when one uses
> > REQUIRE-MATCH, the function finds the entry for INITIAL-INPUT so that the
> > next thing that gets shown after that starts from the one following the
> > match in COLLECTION. Otherwise, one is forced to put the INITIAL-INPUT
> > entry at the end of COLLECTION.
> 
> 
> Sorry, I still don't understand: what are "the following element" and
> "the next thing that gets shown"? Shown how? What causes them to be
> shown?

The collection COLLECJ is this ordered sequence 

"boxplus" "boxtimes" "Cap" "centerdot" "circledast"

with the call to COMPLETING-READ being

(completing-read "PROMPT: " collecj nil t "boxplus")))

Where REQUIRE-MATCH is t

and INITIAL-INPUT is "boxplus"

Now, the user gets the prompt with "boxplus" displayed.

The user moves to the next completion candidate, which is also "boxplus",
the entry at the beginning of COLLECTION.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Eli Zaretskii]

tags 65348 notabug
close 65348
thanks

> Date: Thu, 17 Aug 2023 10:27:27 +0000
> From: Heime <heimeborgia@protonmail.com>
> Cc: 65348@debbugs.gnu.org
> 
> The collection COLLECJ is this ordered sequence 
> 
> "boxplus" "boxtimes" "Cap" "centerdot" "circledast"
> 
> with the call to COMPLETING-READ being
> 
> (completing-read "PROMPT: " collecj nil t "boxplus")))
> 
> Where REQUIRE-MATCH is t
> 
> and INITIAL-INPUT is "boxplus"
> 
> Now, the user gets the prompt with "boxplus" displayed.
> 
> The user moves to the next completion candidate, which is also "boxplus",
> the entry at the beginning of COLLECTION.

Which is why the ELisp manual says:

     The argument INITIAL is mostly deprecated; we recommend using a
     non-‘nil’ value only in conjunction with specifying a cons cell for
     HISTORY.  *Note Initial Input::.  For default input, use DEFAULT
     instead.

In any case, the fact that you see "boxplus" as the first suggestion
of the "future history" is because you both added it to COLLECTION and
set INITIAL to it.  So showing it as the first suggestion is exactly
what completing-read should do in this case.

This is not a bug, and so I'm closing it.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sent with Proton Mail secure email.

------- Original Message -------
On Thursday, August 17th, 2023 at 10:45 PM, Eli Zaretskii <eliz@gnu.org> wrote:


> tags 65348 notabug
> close 65348
> thanks
> 
> > Date: Thu, 17 Aug 2023 10:27:27 +0000
> > From: Heime heimeborgia@protonmail.com
> > Cc: 65348@debbugs.gnu.org
> > 
> > The collection COLLECJ is this ordered sequence
> > 
> > "boxplus" "boxtimes" "Cap" "centerdot" "circledast"
> > 
> > with the call to COMPLETING-READ being
> > 
> > (completing-read "PROMPT: " collecj nil t "boxplus")))
> > 
> > Where REQUIRE-MATCH is t
> > 
> > and INITIAL-INPUT is "boxplus"
> > 
> > Now, the user gets the prompt with "boxplus" displayed.
> > 
> > The user moves to the next completion candidate, which is also "boxplus",
> > the entry at the beginning of COLLECTION.
> 
> 
> Which is why the ELisp manual says:
> 
> The argument INITIAL is mostly deprecated; we recommend using a
> non-‘nil’ value only in conjunction with specifying a cons cell for
> HISTORY. *Note Initial Input::. For default input, use DEFAULT
> instead.
> 
> In any case, the fact that you see "boxplus" as the first suggestion
> of the "future history" is because you both added it to COLLECTION and
> set INITIAL to it. So showing it as the first suggestion is exactly
> what completing-read should do in this case.
> 
> This is not a bug, and so I'm closing it.

So one is not supposed to have the value in COLLECTION if it has been specified
in INITIAL ?

I find using INITIAL quite useful because the user sees something filled up.
What is one to do instead ?  

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Drew Adams]

> > Which is why the ELisp manual says:
> >
> > The argument INITIAL is mostly deprecated; we recommend using a
> > non-‘nil’ value only in conjunction with specifying a cons cell for
> > HISTORY. *Note Initial Input::. For default input, use DEFAULT
> > instead.
> >
> > In any case, the fact that you see "boxplus" as the first suggestion
> > of the "future history" is because you both added it to COLLECTION and
> > set INITIAL to it. So showing it as the first suggestion is exactly
> > what completing-read should do in this case.
> >
> > This is not a bug, and so I'm closing it.
> 
> So one is not supposed to have the value in COLLECTION if it has been
> specified
> in INITIAL ?
> 
> I find using INITIAL quite useful because the user sees something filled
> up. What is one to do instead ?

I think it's only recently that Someone(TM)
thought it was a good idea to add all of
COLLECTION to the "future history".

Previously, the designer of a particular call
to `completing-read' could control the future
history by explicitly giving it what it was
originally designed to have: a specific DEFAULT
value or values.  The designer controlled not
only the members of the future history but
their order.  Alas, no more.

IMO the blind, unavoidable, automatic addition
of COLLECTION to the future history should be
expunged as a misguided misfeature. 

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Eli Zaretskii]

> Date: Fri, 18 Aug 2023 00:35:09 +0000
> From: Heime <heimeborgia@protonmail.com>
> Cc: 65348@debbugs.gnu.org
> 
> So one is not supposed to have the value in COLLECTION if it has been specified
> in INITIAL ?

You _can_ have it there.  It does work.

> I find using INITIAL quite useful because the user sees something filled up.
> What is one to do instead ?  

Why do you need INITIAL?

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sent with Proton Mail secure email.

------- Original Message -------
On Friday, August 18th, 2023 at 3:49 PM, Eli Zaretskii <eliz@gnu.org> wrote:


> > Date: Fri, 18 Aug 2023 00:35:09 +0000
> > From: Heime heimeborgia@protonmail.com
> > Cc: 65348@debbugs.gnu.org
> > 
> > So one is not supposed to have the value in COLLECTION if it has been specified
> > in INITIAL ?
> 
> 
> You can have it there. It does work.

But you are designating it as deprecated, which makes others think that something
awful is going to happen to it.  The introduction of HIST is only making a good
function quite terrible to use, becoming an over-engineering piece of junk to avoid.  
 
> > I find using INITIAL quite useful because the user sees something filled up.
> > What is one to do instead ?
> 
> 
> Why do you need INITIAL?

I want the user to see a default without having him to get it with the bloody "M-n".

Having the user yank it from the default to the minibuffer is a bother, not a way to 
make things easier.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Eli Zaretskii]

> Date: Fri, 18 Aug 2023 05:13:46 +0000
> From: Heime <heimeborgia@protonmail.com>
> Cc: 65348@debbugs.gnu.org
> 
> > You can have it there. It does work.
> 
> But you are designating it as deprecated, which makes others think that something
> awful is going to happen to it.

The manual tells you what to do instead.

> > Why do you need INITIAL?
> 
> I want the user to see a default without having him to get it with the bloody "M-n".

That's not how you show the default to the user.  The way to show the
default to the user is to include it in the prompt, like so:

   Type your choice (default foo):

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sent with Proton Mail secure email.

------- Original Message -------
On Friday, August 18th, 2023 at 5:36 PM, Eli Zaretskii <eliz@gnu.org> wrote:


> > Date: Fri, 18 Aug 2023 05:13:46 +0000
> > From: Heime heimeborgia@protonmail.com
> > Cc: 65348@debbugs.gnu.org
> > 
> > > You can have it there. It does work.
> > 
> > But you are designating it as deprecated, which makes others think that something
> > awful is going to happen to it.
> 
> 
> The manual tells you what to do instead.

This used to be easy for beginners.  Now it has became complicated.  Had hoped 
the plan for the future was to improve things for beginners, now everything has
started to get modified for use mostly by experts.     
 
> > > Why do you need INITIAL?
> > 
> > I want the user to see a default without having him to get it with the bloody "M-n".
> 
> 
> That's not how you show the default to the user. The way to show the
> default to the user is to include it in the prompt, like so:
> 
> Type your choice (default foo):

I do not want the user to type it, but for it to be displayed automatically.
And if theyy do not want the default, they can step to the next possibility
in COLLECTION.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Eli Zaretskii]

> Date: Fri, 18 Aug 2023 05:56:04 +0000
> From: Heime <heimeborgia@protonmail.com>
> Cc: 65348@debbugs.gnu.org
> 
> > The manual tells you what to do instead.
> 
> This used to be easy for beginners.  Now it has became complicated.

Using completing-read was never easy.

> Had hoped the plan for the future was to improve things for
> beginners, now everything has started to get modified for use mostly
> by experts.

The Emacs development enhances the existing functionality, and that
inevitably makes some situations more complex to handle.  That is the
price for added functionality, and no one has yet found a way of
making software more flexible and powerful without also making it more
complex.

> > > > Why do you need INITIAL?
> > > 
> > > I want the user to see a default without having him to get it with the bloody "M-n".
> > 
> > 
> > That's not how you show the default to the user. The way to show the
> > default to the user is to include it in the prompt, like so:
> > 
> > Type your choice (default foo):
> 
> I do not want the user to type it, but for it to be displayed automatically.
> And if theyy do not want the default, they can step to the next possibility
> in COLLECTION.

Then you will have to override the value of
minibuffer-default-add-function with a function of your own.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sent with Proton Mail secure email.

------- Original Message -------
On Friday, August 18th, 2023 at 6:32 PM, Eli Zaretskii <eliz@gnu.org> wrote:


> > Date: Fri, 18 Aug 2023 05:56:04 +0000
> > From: Heime heimeborgia@protonmail.com
> > Cc: 65348@debbugs.gnu.org
> > 
> > > The manual tells you what to do instead.
> > 
> > This used to be easy for beginners. Now it has became complicated.
> 
> 
> Using completing-read was never easy.
> 
> > Had hoped the plan for the future was to improve things for
> > beginners, now everything has started to get modified for use mostly
> > by experts.
> 
> 
> The Emacs development enhances the existing functionality, and that
> inevitably makes some situations more complex to handle. That is the
> price for added functionality, and no one has yet found a way of
> making software more flexible and powerful without also making it more
> complex.
> 
> > > > > Why do you need INITIAL?
> > > > 
> > > > I want the user to see a default without having him to get it with the bloody "M-n".
> > > 
> > > That's not how you show the default to the user. The way to show the
> > > default to the user is to include it in the prompt, like so:
> > > 
> > > Type your choice (default foo):
> > 
> > I do not want the user to type it, but for it to be displayed automatically.
> > And if theyy do not want the default, they can step to the next possibility
> > in COLLECTION.
> 
> 
> Then you will have to override the value of
> minibuffer-default-add-function with a function of your own.

You see how things have become even more complicated now.  How about 
providing the feature that there was ?   

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Eli Zaretskii]

> Date: Fri, 18 Aug 2023 08:40:12 +0000
> From: uzibalqa <uzibalqa@proton.me>
> Cc: Heime <heimeborgia@protonmail.com>, 65348@debbugs.gnu.org
> 
> > The Emacs development enhances the existing functionality, and that
> > inevitably makes some situations more complex to handle. That is the
> > price for added functionality, and no one has yet found a way of
> > making software more flexible and powerful without also making it more
> > complex.
> > 
> > > > > > Why do you need INITIAL?
> > > > > 
> > > > > I want the user to see a default without having him to get it with the bloody "M-n".
> > > > 
> > > > That's not how you show the default to the user. The way to show the
> > > > default to the user is to include it in the prompt, like so:
> > > > 
> > > > Type your choice (default foo):
> > > 
> > > I do not want the user to type it, but for it to be displayed automatically.
> > > And if theyy do not want the default, they can step to the next possibility
> > > in COLLECTION.
> > 
> > 
> > Then you will have to override the value of
> > minibuffer-default-add-function with a function of your own.
> 
> You see how things have become even more complicated now.  How about 
> providing the feature that there was ?   

I explained above why this happens, so there's no need to reiterate.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors]

------- Original Message -------
On Saturday, August 19th, 2023 at 12:14 AM, Eli Zaretskii <eliz@gnu.org> wrote:


> > Date: Fri, 18 Aug 2023 08:40:12 +0000
> > From: uzibalqa uzibalqa@proton.me
> > Cc: Heime heimeborgia@protonmail.com, 65348@debbugs.gnu.org
> > 
> > > The Emacs development enhances the existing functionality, and that
> > > inevitably makes some situations more complex to handle. That is the
> > > price for added functionality, and no one has yet found a way of
> > > making software more flexible and powerful without also making it more
> > > complex.
> > > 
> > > > > > > Why do you need INITIAL?
> > > > > > 
> > > > > > I want the user to see a default without having him to get it with the bloody "M-n".
> > > > > 
> > > > > That's not how you show the default to the user. The way to show the
> > > > > default to the user is to include it in the prompt, like so:
> > > > > 
> > > > > Type your choice (default foo):
> > > > 
> > > > I do not want the user to type it, but for it to be displayed automatically.
> > > > And if theyy do not want the default, they can step to the next possibility
> > > > in COLLECTION.
> > > 
> > > Then you will have to override the value of
> > > minibuffer-default-add-function with a function of your own.
> > 
> > You see how things have become even more complicated now. How about
> > providing the feature that there was ?
> 
> I explained above why this happens, so there's no need to reiterate.

Why have users make new functions to override the value of 
'minibuffer-default-add-function' when you can have the sensible feature
that many would like to use available !  

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Eli Zaretskii]

> Date: Fri, 18 Aug 2023 12:27:47 +0000
> From: Heime <heimeborgia@protonmail.com>
> Cc: uzibalqa <uzibalqa@proton.me>, 65348@debbugs.gnu.org
> 
> > > > Then you will have to override the value of
> > > > minibuffer-default-add-function with a function of your own.
> > > 
> > > You see how things have become even more complicated now. How about
> > > providing the feature that there was ?
> > 
> > I explained above why this happens, so there's no need to reiterate.
> 
> Why have users make new functions to override the value of 
> 'minibuffer-default-add-function' when you can have the sensible feature
> that many would like to use available !  

Because it is needed to support the new enhancements.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sent with Proton Mail secure email.

------- Original Message -------
On Saturday, August 19th, 2023 at 12:30 AM, Eli Zaretskii <eliz@gnu.org> wrote:


> > Date: Fri, 18 Aug 2023 12:27:47 +0000
> > From: Heime heimeborgia@protonmail.com
> > Cc: uzibalqa uzibalqa@proton.me, 65348@debbugs.gnu.org
> > 
> > > > > Then you will have to override the value of
> > > > > minibuffer-default-add-function with a function of your own.
> > > > 
> > > > You see how things have become even more complicated now. How about
> > > > providing the feature that there was ?
> > > 
> > > I explained above why this happens, so there's no need to reiterate.
> > 
> > Why have users make new functions to override the value of
> > 'minibuffer-default-add-function' when you can have the sensible feature
> > that many would like to use available !
> 
> 
> Because it is needed to support the new enhancements.

How would one write this function you mention ?  Or, can such function
also be included part of the new enhancements ? 

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Eli Zaretskii]

> Date: Fri, 18 Aug 2023 12:55:30 +0000
> From: Heime <heimeborgia@protonmail.com>
> Cc: uzibalqa@proton.me, 65348@debbugs.gnu.org
> 
> How would one write this function you mention ?  Or, can such function
> also be included part of the new enhancements ? 

These questions belongs to help-gnu-emacs, not to the bug tracker.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sent with Proton Mail secure email.

------- Original Message -------
On Saturday, August 19th, 2023 at 1:27 AM, Eli Zaretskii <eliz@gnu.org> wrote:


> > Date: Fri, 18 Aug 2023 12:55:30 +0000
> > From: Heime heimeborgia@protonmail.com
> > Cc: uzibalqa@proton.me, 65348@debbugs.gnu.org
> > 
> > How would one write this function you mention ? Or, can such function
> > also be included part of the new enhancements ?
> 
> 
> These questions belongs to help-gnu-emacs, not to the bug tracker.

The history part should have been made as an enhancement rather than
a requirement.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Drew Adams]

> > You can have it there. It does work.
> 
> But you are designating it as deprecated, which makes
> others think that something awful is going to happen to it.

Agreed.  Better to not deprecate it and just explain
the pros and the cons.  However, Emacs deprecated it
long ago...

Deprecation shouldn't be used for this kind of
_stylistic choice_.  For that, when those deciding
agree on what's the best style, and they agree that
it's helpful to pass along their suggestion in the
interest of consistency (for example), then it can
be advertised as a stylistic _convention_.

IMHO, there was never any call for this to be
branded as "deprecated".  I said so at the time,
but other voices prevailed.  History.
___


[FWIW, Icicles considers it not deprecated.  The doc
 string of `completing-read' in Icicle mode has this:

  INITIAL-INPUT is considered deprecated by vanilla
  Emacs, but not by Icicles.  If INITIAL-INPUT is
  nil and DEF is non-nil, the user can use
  `next-history-element' to yank DEF into the
  minibuffer.

 In addition, with Icicles users can choose the
 behavior they prefer wrt inserting the DEFAULT
 value, showing it in the prompt, and selecting it
 if inserted.

 See https://www.emacswiki.org/emacs/Icicles_-_Customization_and_General_Tips#icicle-default-value.

 ]

> The introduction of HIST is only making a good
> function quite terrible to use, becoming an
> over-engineering piece of junk to avoid.

Useless to claim, without saying why you think so.
And you're quite wrong here, FWIW.  HIST is your
friend.

[But minibuffer history too can be improved for users:
 https://www.emacswiki.org/emacs/Icicles_-_History_Enhancements.
 ]

> > > I find using INITIAL quite useful because the
> > > user sees something filled up.

Yes.  More importantly, it's there for you to edit.

As with everything else, inserting it isn't always
a plus or always a minus, and different users can
find it a plus or minus in the same context.

Callers of `completing-read' can decide whether it
makes sense (they think) to insert.  And users
should be able to override the caller's choice.

> Having the user yank it from the default to the
> minibuffer is a bother

Having it inserted automatically can also be a
bother.  Different contexts (different calls to
`completing-read') can call for different behavior,
and different users can, and do, have different
ideas about what behavior is more bothersome.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Drew Adams]

> > > How would one write this function you mention ? Or, can such function
> > > also be included part of the new enhancements ?
> >
> > These questions belongs to help-gnu-emacs, not to the bug tracker.
> 
> The history part should have been made as an enhancement rather than
> a requirement.

That belongs in emacs-devel@gnu.org, if you intend to
open a discussion of your "should" opinion/proposal.

But without specific supporting arguments such a
"should" is useless, and better avoided,.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors]

------- Original Message -------
On Saturday, August 19th, 2023 at 3:16 AM, Drew Adams <drew.adams@oracle.com> wrote:


> > > You can have it there. It does work.
> > 
> > But you are designating it as deprecated, which makes
> > others think that something awful is going to happen to it.
> 
> 
> Agreed. Better to not deprecate it and just explain
> the pros and the cons. However, Emacs deprecated it
> long ago...
> 
> Deprecation shouldn't be used for this kind of
> stylistic choice. For that, when those deciding
> agree on what's the best style, and they agree that
> it's helpful to pass along their suggestion in the
> interest of consistency (for example), then it can
> be advertised as a stylistic convention.
> 
> IMHO, there was never any call for this to be
> branded as "deprecated". I said so at the time,
> but other voices prevailed. History.
> ___
> 
> 
> [FWIW, Icicles considers it not deprecated. The doc
> string of `completing-read' in Icicle mode has this: INITIAL-INPUT is considered deprecated by vanilla Emacs, but not by Icicles. If INITIAL-INPUT is nil and DEF is non-nil, the user can use` next-history-element' to yank DEF into the
> minibuffer.
> 
> In addition, with Icicles users can choose the
> behavior they prefer wrt inserting the DEFAULT
> value, showing it in the prompt, and selecting it
> if inserted.
> 
> See https://www.emacswiki.org/emacs/Icicles_-_Customization_and_General_Tips#icicle-default-value.
> 
> ]
> 
> > The introduction of HIST is only making a good
> > function quite terrible to use, becoming an
> > over-engineering piece of junk to avoid.
> 
> Useless to claim, without saying why you think so.
> And you're quite wrong here, FWIW. HIST is your
> friend.

When using my own function that selects from a collection, I am never 
interested in the history.  Just want it to cycle through the entries,
that's all.  And the less things I got to type, the better.
 
> [But minibuffer history too can be improved for users:
> https://www.emacswiki.org/emacs/Icicles_-_History_Enhancements.
> ]
> 
> > > > I find using INITIAL quite useful because the
> > > > user sees something filled up.
> 
> 
> Yes. More importantly, it's there for you to edit.
> 
> As with everything else, inserting it isn't always
> a plus or always a minus, and different users can
> find it a plus or minus in the same context.
> 
> Callers of `completing-read' can decide whether it
> makes sense (they think) to insert. And users
> should be able to override the caller's choice.

It seems that now I have to know all about the HIST things,
the DEF, the over-riding of same value to call some function 
that I have to write to get the behaviour I was using, etc. 
 
> > Having the user yank it from the default to the
> > minibuffer is a bother
> 
> 
> Having it inserted automatically can also be a
> bother. Different contexts (different calls to
> `completing-read') can call for different behavior,
> and different users can, and do, have different
> ideas about what behavior is more bothersome.

Right.  But if someone wants it displayed immediately, have
to use M-n becomes a bother.  

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Drew Adams]

> > > The introduction of HIST is only making a good
> > > function quite terrible to use, becoming an
> > > over-engineering piece of junk to avoid.
> >
> > Useless to claim, without saying why you think so.
> > And you're quite wrong here, FWIW. HIST is your
> > friend.
> 
> When using my own function that selects from a collection, I am never
> interested in the history.  Just want it to cycle through the entries,
> that's all.  And the less things I got to type, the better.

Everyone is different.

But know that cycling is not always an efficient
way to get to something.  It can be fine if the
thing you want to get to is close by.  It can be
_awful_ if it's far.

This is why we have keys such as `M-r' and `M-s'
that find things in the history.

It can also help to have completion against the
history.  (If you'd read the page I pointed to
about Icicles history enhancements you'd have
seen more than one possibility for that.)

Cycling can be helpful for accessing COLLECTION
matches or for accessing history elements.  But
cycling is an inherently dumb, inefficient way
to find a needle in a haystack.  A magnet works
better than checking each bit of hay in turn.

Being able to sort completion candidates is one
way to tame dumb cycling.  Being able to filter
them is another.  It's really important to have
ways to tame a large set of choices, whether
they are completion candidates, input-history
candidates, or anything else.

> > Callers of `completing-read' can decide whether it
> > makes sense (they think) to insert. And users
> > should be able to override the caller's choice.
> 
> It seems that now I have to know all about the HIST things,
> the DEF, the over-riding of same value to call some function
> that I have to write to get the behaviour I was using, etc.

You don't have to know anything.  And yes, there
are a multitude of things you can learn, to make
your Emacs life easier, more efficient, more
enjoyable, more enlightening.

Some people use Emacs for a long time without
bothering to learn other ways of doing things
than what they learned the first week.  Some use
menus and mouse alone, pretty much.  Others get
along better as time goes on, picking up various
ways to do things easier or quicker.  Often that
includes writing some code or picking up some
code (e.g. packages) written by others.  YMMV.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors]

------- Original Message -------
On Saturday, August 19th, 2023 at 5:33 AM, Drew Adams <drew.adams@oracle.com> wrote:


> > > > The introduction of HIST is only making a good
> > > > function quite terrible to use, becoming an
> > > > over-engineering piece of junk to avoid.
> > > 
> > > Useless to claim, without saying why you think so.
> > > And you're quite wrong here, FWIW. HIST is your
> > > friend.
> > 
> > When using my own function that selects from a collection, I am never
> > interested in the history. Just want it to cycle through the entries,
> > that's all. And the less things I got to type, the better.
> 
> 
> Everyone is different.
> 
> But know that cycling is not always an efficient
> way to get to something. It can be fine if the
> thing you want to get to is close by. It can be
> awful if it's far.
> 
> This is why we have keys such as `M-r' and` M-s'
> that find things in the history.
> 
> It can also help to have completion against the
> history. (If you'd read the page I pointed to
> about Icicles history enhancements you'd have
> seen more than one possibility for that.)
> 
> Cycling can be helpful for accessing COLLECTION
> matches or for accessing history elements. But
> cycling is an inherently dumb, inefficient way
> to find a needle in a haystack. A magnet works
> better than checking each bit of hay in turn.

I use completing-read so I do not have to remember 
collection matches. 
 
> Being able to sort completion candidates is one
> way to tame dumb cycling. Being able to filter
> them is another. It's really important to have
> ways to tame a large set of choices, whether
> they are completion candidates, input-history
> candidates, or anything else.
> 
> > > Callers of `completing-read' can decide whether it
> > > makes sense (they think) to insert. And users
> > > should be able to override the caller's choice.
> > 
> > It seems that now I have to know all about the HIST things,
> > the DEF, the over-riding of same value to call some function
> > that I have to write to get the behaviour I was using, etc.
> 
> 
> You don't have to know anything. And yes, there
> are a multitude of things you can learn, to make
> your Emacs life easier, more efficient, more
> enjoyable, more enlightening.
> 
> Some people use Emacs for a long time without
> bothering to learn other ways of doing things
> than what they learned the first week. Some use
> menus and mouse alone, pretty much. Others get
> along better as time goes on, picking up various
> ways to do things easier or quicker. Often that
> includes writing some code or picking up some
> code (e.g. packages) written by others. YMMV.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sent with Proton Mail secure email.

------- Original Message -------
On Saturday, August 19th, 2023 at 5:33 AM, Drew Adams <drew.adams@oracle.com> wrote:


> > > > The introduction of HIST is only making a good
> > > > function quite terrible to use, becoming an
> > > > over-engineering piece of junk to avoid.
> > > 
> > > Useless to claim, without saying why you think so.
> > > And you're quite wrong here, FWIW. HIST is your
> > > friend.
> > 
> > When using my own function that selects from a collection, I am never
> > interested in the history. Just want it to cycle through the entries,
> > that's all. And the less things I got to type, the better.
> 
> Everyone is different.

Fine.  But I cannot see the reason to forced mo to override the value of 
'minibuffer-default-add-function' with a function of my own.

Would that not change the way that completing-read works for all my emacs 
sessions ?  How about having a different function with functionality that
supports the old functionality.  There will be the simpler version, and a
more complicated one should people need it.  I cannot see how adding the
new functionality means scrapping the legitimate way that I was using it.
 
> But know that cycling is not always an efficient
> way to get to something. It can be fine if the
> thing you want to get to is close by. It can be
> awful if it's far.
> 
> This is why we have keys such as `M-r' and` M-s'
> that find things in the history.
> 
> It can also help to have completion against the
> history. (If you'd read the page I pointed to
> about Icicles history enhancements you'd have
> seen more than one possibility for that.)
> 
> Cycling can be helpful for accessing COLLECTION
> matches or for accessing history elements. But
> cycling is an inherently dumb, inefficient way
> to find a needle in a haystack. A magnet works
> better than checking each bit of hay in turn.
> 
> Being able to sort completion candidates is one
> way to tame dumb cycling. Being able to filter
> them is another. It's really important to have
> ways to tame a large set of choices, whether
> they are completion candidates, input-history
> candidates, or anything else.
> 
> > > Callers of `completing-read' can decide whether it
> > > makes sense (they think) to insert. And users
> > > should be able to override the caller's choice.
> > 
> > It seems that now I have to know all about the HIST things,
> > the DEF, the over-riding of same value to call some function
> > that I have to write to get the behaviour I was using, etc.
> 
> 
> You don't have to know anything. And yes, there
> are a multitude of things you can learn, to make
> your Emacs life easier, more efficient, more
> enjoyable, more enlightening.
> 
> Some people use Emacs for a long time without
> bothering to learn other ways of doing things
> than what they learned the first week. Some use
> menus and mouse alone, pretty much. Others get
> along better as time goes on, picking up various
> ways to do things easier or quicker. Often that
> includes writing some code or picking up some
> code (e.g. packages) written by others. YMMV.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Drew Adams]

> > Cycling can be helpful for accessing COLLECTION
> > matches or for accessing history elements. But
> > cycling is an inherently dumb, inefficient way
> > to find a needle in a haystack. A magnet works
> > better than checking each bit of hay in turn.
> 
> I use completing-read so I do not have to remember
> collection matches.

  "Remember collection matches?"
No idea what you're on about, there.

The point is that cycling among `completing-read'
completion candidates, just like cycling among
`completing-read' history elements, is a slow,
single-step, brute-force way to access choices.
If there are _many_ candidates then it becomes a
ridiculous way to get what you want.  In that case
you're far better off filtering the candidates.

When you use `completing-read', you _do_ sometimes
type some text in the minibuffer, to filter the
choices, don't you?  Why do you do that, instead
of just cycling blindly among ALL the candidates
in the domain (COLLECTION)?  Because it's stupid
& slow to cycle when there are zillions of choices.

 M-x TAB <down> <down> <down> <down> <down>...

You DON'T do that to enter a command, do you?  I
truly hope you type some text before hitting TAB.

The same thing applies to accessing a choice among
_any_ set of candidates, whether it's completions,
history elements, query-replace matches,...

Filtering is _far_ more efficient than cycling
when the set of candidates is large.  Emacs makes
a point of giving users ways to filter instead of
just checking each blade of straw to see if it
might be a needle.

Filter first, well, and often, and it will boost
the value of _cycling_.  Same for sorting: sort
well and you needn't cycle much.  Cycling on its
own is like reading a novel one letter at a time.

Cycling is the _last_ thing to do, after you've
narrowed the selection down to a few choices and
if it's more trouble than it's worth to narrow it
down to a single choice by filtering further.

If you can present the choices in a good order
(sorting) then it might not matter how many there
are, because you have, in effect, narrowed the
choices down to those at the start of the list.

Being able to sort completion candidates on the
fly is powerful, as is being able to filter them
on the fly - and to filter again and again, with
different criteria/patterns.

Vanilla Emacs doesn't offer filtering again and
again; and it doesn't offer sorting on the fly.
It should offer both.
___

https://www.emacswiki.org/emacs/Icicles_-_Nutshell_View#ProgressiveCompletion

https://www.emacswiki.org/emacs/Icicles_-_Sorting_Candidates

https://www.emacswiki.org/emacs/Icicles_-_Sorting_Candidates#screenshots

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Drew Adams]

> > > When using my own function that selects from a collection, I am never
> > > interested in the history. Just want it to cycle through the entries,
> > > that's all. And the less things I got to type, the better.
> >
> > Everyone is different.
> 
> Fine.  But I cannot see the reason to forced mo to override the value of
> 'minibuffer-default-add-function' with a function of my own.

I have nothing to say about that variable,
except to repeat what I already said about
the Emacs change to add COLLECTION to the
future history: It's a misguided misfeature.

Never shoulda happened.  Isn't helpful.
Just one opinion.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors]

------- Original Message -------
On Saturday, August 19th, 2023 at 9:03 AM, Drew Adams <drew.adams@oracle.com> wrote:


> > > Cycling can be helpful for accessing COLLECTION
> > > matches or for accessing history elements. But
> > > cycling is an inherently dumb, inefficient way
> > > to find a needle in a haystack. A magnet works
> > > better than checking each bit of hay in turn.
> > 
> > I use completing-read so I do not have to remember
> > collection matches.
> 
> 
> "Remember collection matches?"
> No idea what you're on about, there.
> 
> The point is that cycling among `completing-read' completion candidates, just like cycling among` completing-read' history elements, is a slow,
> single-step, brute-force way to access choices.
> If there are many candidates then it becomes a
> ridiculous way to get what you want. In that case
> you're far better off filtering the candidates.
> 
> When you use `completing-read', you do sometimes
> type some text in the minibuffer, to filter the
> choices, don't you? Why do you do that, instead
> of just cycling blindly among ALL the candidates
> in the domain (COLLECTION)? Because it's stupid
> & slow to cycle when there are zillions of choices.
> 
> M-x TAB <down> <down> <down> <down> <down>...
>
> You DON'T do that to enter a command, do you? I
> truly hope you type some text before hitting TAB.

I do actually and without hitting TAB.  Did not know about that
trick.
 
> The same thing applies to accessing a choice among
> any set of candidates, whether it's completions,
> history elements, query-replace matches,...
> 
> Filtering is far more efficient than cycling
> when the set of candidates is large. Emacs makes
> a point of giving users ways to filter instead of
> just checking each blade of straw to see if it
> might be a needle.
> 
> Filter first, well, and often, and it will boost
> the value of cycling. Same for sorting: sort
> well and you needn't cycle much. Cycling on its
> own is like reading a novel one letter at a time.

I like to categorise rather than sort.
 
> Cycling is the last thing to do, after you've
> narrowed the selection down to a few choices and
> if it's more trouble than it's worth to narrow it
> down to a single choice by filtering further.
> 
> If you can present the choices in a good order
> (sorting) then it might not matter how many there
> are, because you have, in effect, narrowed the
> choices down to those at the start of the list.
> 
> Being able to sort completion candidates on the
> fly is powerful, as is being able to filter them
> on the fly - and to filter again and again, with
> different criteria/patterns.
> 
> Vanilla Emacs doesn't offer filtering again and
> again; and it doesn't offer sorting on the fly.
> It should offer both.

It should as you say.
 
> https://www.emacswiki.org/emacs/Icicles_-_Nutshell_View#ProgressiveCompletion
> 
> https://www.emacswiki.org/emacs/Icicles_-_Sorting_Candidates
> 
> https://www.emacswiki.org/emacs/Icicles_-_Sorting_Candidates#screenshots

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors]

------- Original Message -------
On Saturday, August 19th, 2023 at 7:12 AM, Heime via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> wrote:

> ------- Original Message -------
> On Saturday, August 19th, 2023 at 5:33 AM, Drew Adams drew.adams@oracle.com wrote:
> 
> > > > > The introduction of HIST is only making a good
> > > > > function quite terrible to use, becoming an
> > > > > over-engineering piece of junk to avoid.
> > > > 
> > > > Useless to claim, without saying why you think so.
> > > > And you're quite wrong here, FWIW. HIST is your
> > > > friend.
> > > 
> > > When using my own function that selects from a collection, I am never
> > > interested in the history. Just want it to cycle through the entries,
> > > that's all. And the less things I got to type, the better.
> > 
> > Everyone is different.
> > 
> > But know that cycling is not always an efficient
> > way to get to something. It can be fine if the
> > thing you want to get to is close by. It can be
> > awful if it's far.
> > 
> > This is why we have keys such as `M-r' and` M-s'
> > that find things in the history.
> > 
> > It can also help to have completion against the
> > history. (If you'd read the page I pointed to
> > about Icicles history enhancements you'd have
> > seen more than one possibility for that.)
> > 
> > Cycling can be helpful for accessing COLLECTION
> > matches or for accessing history elements. But
> > cycling is an inherently dumb, inefficient way
> > to find a needle in a haystack. A magnet works
> > better than checking each bit of hay in turn.

Would it not be better to COLLECTION and HISTORY separate ? 
 
> I use completing-read so I do not have to remember
> collection matches.
> 
> > Being able to sort completion candidates is one
> > way to tame dumb cycling. Being able to filter
> > them is another. It's really important to have
> > ways to tame a large set of choices, whether
> > they are completion candidates, input-history
> > candidates, or anything else.

I can put a question so I can see how I can use what you are suggesting.
See if it works for me. 
 
> > > > Callers of `completing-read' can decide whether it
> > > > makes sense (they think) to insert. And users
> > > > should be able to override the caller's choice.
> > > 
> > > It seems that now I have to know all about the HIST things,
> > > the DEF, the over-riding of same value to call some function
> > > that I have to write to get the behaviour I was using, etc.
> > 
> > You don't have to know anything. And yes, there
> > are a multitude of things you can learn, to make
> > your Emacs life easier, more efficient, more
> > enjoyable, more enlightening.
> > 
> > Some people use Emacs for a long time without
> > bothering to learn other ways of doing things
> > than what they learned the first week. Some use
> > menus and mouse alone, pretty much. Others get
> > along better as time goes on, picking up various
> > ways to do things easier or quicker. Often that
> > includes writing some code or picking up some
> > code (e.g. packages) written by others. YMMV.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Drew Adams]

> Would it not be better to COLLECTION and HISTORY separate ?

You already have my opinion: yes.  And they always
have been, till Someone (TM) decided recently that
future history should include all of the candidates
in COLLECTION.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sent with Proton Mail secure email.

------- Original Message -------
On Saturday, August 19th, 2023 at 4:14 PM, Drew Adams <drew.adams@oracle.com> wrote:


> > Would it not be better to COLLECTION and HISTORY separate ?
> 
> 
> You already have my opinion: yes. And they always
> have been, till Someone (TM) decided recently that
> future history should include all of the candidates
> in COLLECTION.

Right.  Because entries in history ought to be stored in history
as you input values, not before.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Drew Adams]

> > > Would it not be better to COLLECTION and HISTORY separate ?
> >
> > You already have my opinion: yes. And they always
> > have been, till Someone (TM) decided recently that
> > future history should include all of the candidates
> > in COLLECTION.
> 
> Right.  Because entries in history ought to be stored in history
> as you input values, not before.

Not so, for "future history" (and that's why that cute
term isn't a good one).  The so-called "future history"
is one or more DEFAULT values you can retrieve and use
as input if you like.

After use of DEFAULT (`M-n') got rebaptized as using
"future history", Someone (TM) got the dim idea to add
all of COLLECTION to that list, along with the DEFAULT
values.  DEFAULT values belong, properly, to "future
history" (though that's a misleading misnomer).

But COLLECTION doesn't belong in "future history".
The reason isn't what you gave, though.  It's proper
to fill the "future history" before you choose input,
but it's only proper to fill it with default values.
What's not good is to also fill it with all of the
possible completion choices.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors]

------- Original Message -------
On Saturday, August 19th, 2023 at 4:46 PM, Drew Adams <drew.adams@oracle.com> wrote:

> > > > Would it not be better to COLLECTION and HISTORY separate ?
> > > 
> > > You already have my opinion: yes. And they always
> > > have been, till Someone (TM) decided recently that
> > > future history should include all of the candidates
> > > in COLLECTION.
> > 
> > Right. Because entries in history ought to be stored in history
> > as you input values, not before.
> 
> 
> Not so, for "future history" (and that's why that cute
> term isn't a good one). The so-called "future history"
> is one or more DEFAULT values you can retrieve and use
> as input if you like.
> 
> After use of DEFAULT (`M-n') got rebaptized as using
> "future history", Someone (TM) got the dim idea to add
> all of COLLECTION to that list, along with the DEFAULT
> values. DEFAULT values belong, properly, to "future
> history" (though that's a misleading misnomer).
> 
> But COLLECTION doesn't belong in "future history".
> The reason isn't what you gave, though. It's proper
> to fill the "future history" before you choose input,
> but it's only proper to fill it with default values.
> What's not good is to also fill it with all of the
> possible completion choices.

Eli, would there be some capability to improve the aforementioned
function from the merits held by the discussion that is happening ?

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Eli Zaretskii]

> Date: Sat, 19 Aug 2023 05:05:41 +0000
> From: Heime <heimeborgia@protonmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, "65348@debbugs.gnu.org" <65348@debbugs.gnu.org>
> 
> > Not so, for "future history" (and that's why that cute
> > term isn't a good one). The so-called "future history"
> > is one or more DEFAULT values you can retrieve and use
> > as input if you like.
> > 
> > After use of DEFAULT (`M-n') got rebaptized as using
> > "future history", Someone (TM) got the dim idea to add
> > all of COLLECTION to that list, along with the DEFAULT
> > values. DEFAULT values belong, properly, to "future
> > history" (though that's a misleading misnomer).
> > 
> > But COLLECTION doesn't belong in "future history".
> > The reason isn't what you gave, though. It's proper
> > to fill the "future history" before you choose input,
> > but it's only proper to fill it with default values.
> > What's not good is to also fill it with all of the
> > possible completion choices.
> 
> Eli, would there be some capability to improve the aforementioned
> function from the merits held by the discussion that is happening ?

You can try starting a discussion on emacs-devel if you want.  But the
above-mentioned change was not done arbitrarily, and does have its
merit in many situations, so be prepared for hearing people who think
they like the current situation and object to changing it.  Drew's
opinion on this are not new, and have been heard (and rejected)
before.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Drew Adams]

> You can try starting a discussion on emacs-devel if you want.  But the
> above-mentioned change was not done arbitrarily, and does have its
> merit in many situations,

I don't see that it has merit in any situation.
I haven't seen a single example cited where it
has merit.  Can you point to one?  I really
don't see any value in this behavior.

And I think you agreed that it's obvious that in
some cases (such as the `C-h v' example cited in
bug #64656) it's _clearly_ not helpful but harmful.

> so be prepared for hearing people who think
> they like the current situation and object to changing it.  Drew's
> opinion on this are not new, and have been heard (and rejected)
> before.

I searched but didn't see anywhere where my opinion
on this was rejected.  I think the relevant thread
is that of bug #64656, which you intentionally kept
open for this very question: whether COLLECTION
should be automatically added to "future history".

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64656

Below are some relevant extracts from what I wrote
there.  The question I posed of what value this
"feature" has was never answered.  I'd like to hear
about "its merit in many situations".  You didn't
point to any situations in that bug thread. Do you
have any (let only "many") in mind?

It's an honest question.  I don't get the point of
this feature.  What am I missing?

From bug #64656:
___

But I'm asking about the general idea behind
this default behavior: What use case(s) does
it really help with?  Even with a small list
of (empty-input) completions, and even when
those are in some meaningful/useful order,
what's the use case for adding them to `M-n',
which is a carefully designed default or list
of defaults?  Why use the completion domain
as a set of defaults - at all?
___

1. I'm asking whether this feature (addition
   of completion domain automatically)
   shouldn't be revisited, maybe even removed,
   and at least default to OFF.

2. If that revisit is NOT to be, then I'm
   asking that the doc at least (a) point out
   that this automatic behavior can be
   problematic, and (b) tell users how to
   (i) turn it off and (ii) control it a bit
   if not turned off.  That control can include
   limiting the size and sorting the elements
   to be added.
___

ELI> If we think that future history in some case
ELI> is useless, TRT is to change the code so
ELI> that it ceases to be useless,

100% agreement.  That's why that was my first
priority request.  Fix this and there likely
will be no, or little, need to change the doc.

I didn't assume that others would agree that
the behavior is harmful.

I thought too that I might just be missing
something.  The behavior seems so bizarre to
me that I don't understand why it would have
been adopted.  Benefit of the doubt made me
guess I'm maybe just misunderstanding.
___

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "65348@debbugs.gnu.org" <65348@debbugs.gnu.org>
> Date: Sat, 19 Aug 2023 16:20:07 +0000
> 
> > You can try starting a discussion on emacs-devel if you want.  But the
> > above-mentioned change was not done arbitrarily, and does have its
> > merit in many situations,
> 
> I don't see that it has merit in any situation.

The situations where it's useful are obvious.

> I haven't seen a single example cited where it
> has merit.  Can you point to one?

What for? so you could argue endlessly that you disagree?  We already
know that you don't like that change and think it should be reverted,
so what would be the purpose of another discussion about that?

> And I think you agreed that it's obvious that in
> some cases (such as the `C-h v' example cited in
> bug #64656) it's _clearly_ not helpful but harmful.

In some, quite extreme, case, indeed, it is not useful.  That doesn't
yet mean it is always useless.

Again, we've been through that, and I really have no reason to do it
again.  Life is too short.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Drew Adams]

> > > You can try starting a discussion on emacs-devel if you want.  But the
> > > above-mentioned change was not done arbitrarily, and does have its
> > > merit in many situations,
> >
> > I don't see that it has merit in any situation.
> 
> The situations where it's useful are obvious.

Instead of claiming that, maybe you can point to
one or two?  That shouldn't be hard.  I'd really
like to hear about it.

> > I haven't seen a single example cited where it
> > has merit.  Can you point to one?
> 
> What for? so you could argue endlessly that you disagree?  We already
> know that you don't like that change and think it should be reverted,
> so what would be the purpose of another discussion about that?

C'mon, Eli.  I won't disagree if I see the point.
So far, I haven't seen one example of a use case
or heard one concrete argument for why this helps.

Give it a try.  What's a use case, obvious to you
or not?  What's a reason why you think it helps?

A priori, I would like to see this removed as the
_default_ behavior.  But I don't expect that.
Next best would be a good user option to tame it
or even turn it off altogether.  

> > And I think you agreed that it's obvious that in
> > some cases (such as the `C-h v' example cited in
> > bug #64656) it's _clearly_ not helpful but harmful.
> 
> In some, quite extreme, case, indeed, it is not useful.
> That doesn't yet mean it is always useless.

Agreed.  (Re-agreed, in fact.)

To ask that we be able to tame it doesn't require
a claim that it's always useless.  I don't know
that it's always useless.  I've only said that I
haven't seen an example of when/how it's useful.

In case you're thinking, for your "obvious" use
cases, of a case where you have few completion
candidates, such as just "alpha", "beta", "gamma",
then let's not forget that you can already cycle
among those now, as completion candidates, without
having them added to the future history.  That's
available since Stefan added candidate cycling,
AFAIK.

> Again, we've been through that, and I really have
> no reason to do it again.  Life is too short.

I don't think we've been through this at all.
I expressed my view (so far) that this feature
doesn't help and is generally an obstacle.  But
AFAIK there's been no discussion, pro & con.

You act like there's already been some big
discussion.  I haven't found any.  This is the
most I've written on it, in this little bug
thread, read by maybe 3 people.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors]

------- Original Message -------
On Sunday, August 20th, 2023 at 7:19 AM, Eli Zaretskii <eliz@gnu.org> wrote:


> > From: Drew Adams drew.adams@oracle.com
> > CC: "65348@debbugs.gnu.org" 65348@debbugs.gnu.org
> > Date: Sat, 19 Aug 2023 16:20:07 +0000
> > 
> > > You can try starting a discussion on emacs-devel if you want. But the
> > > above-mentioned change was not done arbitrarily, and does have its
> > > merit in many situations,
> > 
> > I don't see that it has merit in any situation.
> 
> 
> The situations where it's useful are obvious.
> 
> > I haven't seen a single example cited where it
> > has merit. Can you point to one?
> 
> 
> What for? so you could argue endlessly that you disagree? We already
> know that you don't like that change and think it should be reverted,
> so what would be the purpose of another discussion about that?
> 
> > And I think you agreed that it's obvious that in
> > some cases (such as the `C-h v' example cited in
> > bug #64656) it's clearly not helpful but harmful.
> 
> In some, quite extreme, case, indeed, it is not useful. That doesn't
> yet mean it is always useless.

Using a list in collection for cycling using an 'initial-value' ('default-value'
if that what most people would like it to be, is not an extreme case.  
 
> Again, we've been through that, and I really have no reason to do it
> again. Life is too short.

Will 'INITIAL-VALUE' be deprecated and made obsolete.  Then we would be using
'DEF' ?  One thing that bothers me quite a bit is the idea of obsolescence,
but in practice we keep things as they are for the sake of not breaking compatibility
with older versions.  The result is a complicated call definitions that while
they exist, a concurrent rule is actually in effect suggesting others what should
be used and not used.  

While providing multiple ways of accomplishing tasks can offer flexibility and 
accommodate various preferences and use cases, leaving conflicting or redundant
features leads to confusion and complexity for developers working with the codebase.

Deprecation should mean removing them in newer versions with instructions to developers
on migrating to the alternative.

Can there be the option to place an item from the collection (call it 'INITIAL', 'DEF', 'WHATEVER')
that appears as soon as `completing-read` is called ?

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Michael Heerdegen]

Heime via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> Can there be the option to place an item from the collection (call it
> 'INITIAL', 'DEF', 'WHATEVER')
> that appears as soon as `completing-read` is called ?

If I understand correctly and you want still want to start with a
prefilled minibuffer: you can still achieve this by using
`minibuffer-with-setup-hook' - like in

#+begin_src emacs-lisp
(minibuffer-with-setup-hook (lambda () (insert "BBB"))
  (completing-read "Input: " (list "AAA" "BBB" "CCC")))
#+end_src

Michael.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors]

------- Original Message -------
On Sunday, August 20th, 2023 at 6:12 PM, Michael Heerdegen <michael_heerdegen@web.de> wrote:


> Heime via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" bug-gnu-emacs@gnu.org writes:
> 
> > Can there be the option to place an item from the collection (call it
> > 'INITIAL', 'DEF', 'WHATEVER')
> > that appears as soon as `completing-read` is called ?
> 
> 
> If I understand correctly and you want still want to start with a
> prefilled minibuffer: you can still achieve this by using
> `minibuffer-with-setup-hook' - like in
> 
> #+begin_src emacs-lisp
> (minibuffer-with-setup-hook (lambda () (insert "BBB"))
> (completing-read "Input: " (list "AAA" "BBB" "CCC")))
> #+end_src
> 
> Michael.

How complicated my friend from the old single call to 'completing-read'.
I cannot use such thing in all my interactive call functions.  I have seen
so many deliberation about keeping existing functionality  for the old chaps,
yet showing complete disregard on such possibilities on this refilled minibuffer
capability.

The claim that life is too short to give a fuck does not abode well.  

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Christopher Dimech]

> Sent: Sunday, August 20, 2023 at 6:12 PM
> From: "Michael Heerdegen" <michael_heerdegen@web.de>
> To: 65348@debbugs.gnu.org
> Cc: eliz@gnu.org, heimeborgia@protonmail.com, drew.adams@oracle.com
> Subject: bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively
>
> Heime via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs@gnu.org> writes:
>
> > Can there be the option to place an item from the collection (call it
> > 'INITIAL', 'DEF', 'WHATEVER')
> > that appears as soon as `completing-read` is called ?
>
> If I understand correctly and you want still want to start with a
> prefilled minibuffer: you can still achieve this by using
> `minibuffer-with-setup-hook' - like in
>
> #+begin_src emacs-lisp
> (minibuffer-with-setup-hook (lambda () (insert "BBB"))
>   (completing-read "Input: " (list "AAA" "BBB" "CCC")))
> #+end_src
>
> Michael.

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.

>

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Juri Linkov]

> In case you're thinking, for your "obvious" use
> cases, of a case where you have few completion
> candidates, such as just "alpha", "beta", "gamma",
> then let's not forget that you can already cycle
> among those now, as completion candidates, without
> having them added to the future history.  That's
> available since Stefan added candidate cycling,
> AFAIK.

Your answers are too short.  Please elaborate
what do you mean by "candidate cycling" and
what keys do you press to cycle candidates?
Then maybe this cycling could be used instead of 'M-n'.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Drew Adams]

> > In case you're thinking, for your "obvious" use
> > cases, of a case where you have few completion
> > candidates, such as just "alpha", "beta", "gamma",
> > then let's not forget that you can already cycle
> > among those now, as completion candidates, without
> > having them added to the future history.  That's
> > available since Stefan added candidate cycling,
> > AFAIK.
> 
> Your answers are too short.  Please elaborate
> what do you mean by "candidate cycling" and
> what keys do you press to cycle candidates?

Sorry.  First, I'm no expert on the cycling provided
by vanilla Emacs.  I believe Stefan introduced it.
He can probably tell you more, and better.

There are two different completion metadata entries,
`display-sort-function' and `cycle-sort-function'.
See (elisp) `Programmed Completion':

https://www.gnu.org/software/emacs/manual/html_node/elisp/Programmed-Completion.html

(I don't see why anyone would ever want those two to
have different values, but I don't think my ignorance
about that is very relevant here.)

Dunno whether there is some key that, by _default_,
invokes one or the other of those functions.

I use them in a two of my libraries, `sortie.el'
and `keysee.el', to use vanilla Emacs cycling
for cycling and display, together.

With sortie.el, when you hit a key (`C-,' by
default) the candidates in *Completions* are
re-sorted, and so are the candidates you cycle
through (same sort order).  So when you cycle to
a candidate, that's also the current candidate
in *Completions*.

To turn on cycling you need to give
`completion-cycle-threshold' a non-nil value.
Then you can cycle among candidates using `TAB'.

keysee.el uses key descriptions as candidates.
sortie.el uses sort orders (functions) as
candidates.  keysee.el uses sortie.el to let you
change how its candidate key descriptions are
sorted.

In the Commentary of sortie there's a simple
example of using the features it provides.
Here's most of that example:

(defun my-completion-with-sort-cycling ()
  "Read and echo choice using completion with sort-order cycling."
  (interactive)
  (minibuffer-with-setup-hook #'sorti-bind-cycle-key
    (let ((sorti-current-order          'order1)
          (sorti-sort-function-chooser  'my-sort-fn-chooser)
          (sorti-sort-orders-alist      '((order1 . "alphabetical")
                                          (order2 . "by length")))
          (sorti-sort-orders-ring       (let ((rng  (make-ring 4)))
                                          (ring-insert rng 'order1)
                                          (ring-insert rng 'order2)
                                          rng)))
      (message "RESULT: %S"
               (completing-read "fff: "
                                (my-collection-fn
                                 '("aa" "bb" "ab" "aaff" "c")))))))

(defun my-collection-fn (candidates)
  "Collection function that provides metadata for sorting.
Sorting is per the current value of `my-sort-fn-chooser'."
  (lambda (string pred action)
    (if (eq action 'metadata)
        (let ((order  (my-sort-fn-chooser)))
          `(metadata ,@(and order
                            `((display-sort-function . ,order)
                              (cycle-sort-function   . ,order)))))
      (complete-with-action action candidates string pred))))

(defun my-sort-fn-chooser ()
  "Return sort function for current value of `sorti-current-order'."
  (if (eq 'order2 sorti-current-order)
      'my-sort-by-length
    'my-sort-alphabetically))

So for example, with both sortie.el and keysee.el
loaded, if you turn on mode `kc-mode' then

* `S-TAB' shows currently available key bindings.
* `C-,' re-sorts them in a few different ways
  (for both *Completions* display and cycling).
  You cycle among the available sort orders, to
  choose one, with `completing-read'.
* `TAB' cycles among the key bindings, to choose
  one, with `completing-read'.
___

As I say, I don't know how others make use of the
vanilla cycling feature.  Maybe Emacs provides a
key for such cycling by default, but I doubt it.

I think you have to define the cycling yourself,
by defining a function (such as `my-collection-fn'
above) that dynamically sorts the candidates to
produce a COLLECTION that's sorted as desired.

But is it really needed - by default, i.e., in
general - to be able to cycle among all candidates
in COLLECTION?  Certainly some libraries, such as
Icicles, offer that, but it's not as if it's so
essential that vanilla Emacs should provide it by
default, I think.  It makes sense to give coders
ways to provide candidate cycling when they want
it for `completing-read'.

My main point was that IF any such cycling of
COLLECTION entries is provided, it need not, and
should NOT, be part of the history (future or not).
Leave the history cycling to minibuffer input
HISTORY and to DEFAULTS.  If you want cycling of
all candidates in COLLECTION then provide that as
a different kind of cycling (different key).

> Then maybe this cycling could be used instead of 'M-n'.

No, not in my opinion; not at all.

`M-n' should be only for cycling forward in the
history, just as `M-p' should be for cycling
backward.  Users should know that that's what's
being cycled, and that those things are NOT, in
general, candidates from COLLECTION.  (Think lax
completion.)

The "feature" of unequivocally adding COLLECTION
to the history mixes things that don't belong
together.  It doesn't help users, IMO; and it can
confuse them, by mixing carrots with car parts.

My call is to first-and-foremost give control to
(1) users interactively and (2) coders who call
`completing-read'.

We already have a way for any coder to add all of
COLLECTION to the "future history": use it as, or
include it in, the value of argument DEFAULTS.
_End of story._

That gives coders 100% control over such addition.
It's not blindly imposed on them.  And it's easy
to obtain when/if they want it.  Easy peasy.  They
already have COLLECTION - just pass it also as arg
DEFAULTS (or part of DEFAULTS).

Arg DEFAULTS should, _alone_, determine/define the
"future history".  You can do anything you want
with it, including get the current behavior that
gets imposed unilaterally.  But you need not live
with that imposition.

Do I want to argue this in emacs-devel?  Not really.
I really don't have time for such things these days.

But do I wish something were done to remove this
imposition and give control back to coders & users?
Absolutely.  If this makes sense to you, go for it.

And I think it's simple to do: (1) Stop filling
future history with COLLECTION, or at least provide
a simple means to stop that.  (2) Point out to users
that IF they want to for some reason (the "many" use
cases Eli hinted at), they can simply include all of
COLLECTION as, or in, the future history, by just
passing it as (or as part of) the list arg DEFAULTS.

What's more, they can sort it first, any way they
like.  And they can filter it, if they don't want to
include _all_ of COLLECTION.  The current "feature"
is brutal - it's a one-size-fits-none, IMO.  It was
never needed (DEFAULT suffices), and it can't be
turned off.

#2 is maybe not obvious, even though it has been
available since Day One.  If it were really so
useful in "many" situations then I think we would
have seen "many" users pass COLLECTION also as
DEFAULTS (e.g. before Emacs 23).  I seriously doubt
we'v seen many - maybe not even any.

Yet someone thought it was a great idea to impose
that behavior always, on everyone - every call to
`completing-read' that uses an explicit COLLECTION.
Dunno who did that, and as Eli says, apparently it
was done in Emacs 23.  I guess many of us just
never noticed it.

BTW, what about a COLLECTION that's not explicit,
that's realized bit by bit with a function?  That
doesn't work anyway for this "feature", I guess.
You need to manifest an explicit COLLECTION, in
order to add it to any history (history needs to
be manifest for the call to `completing-read').

(I guess if you know the candidate domain you can
use `all-completions' with a function COLLECTION
to get an explicit version, if you really need to
add it to the future history.)

HTH.  And BTW, thanks, Juri, for enhancing DEFAULT
to be able to be a list (long ago).
___

https://www.emacswiki.org/emacs/download/sortie.el

https://www.emacswiki.org/emacs/download/keysee.el

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

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

Let's please keep this function backward-compatible.
If you want something different, please add it as a
separate function.

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

[Christopher Dimech]

> Sent: Monday, August 21, 2023 at 12:25 PM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Christopher Dimech" <dimech@gmx.com>, "Michael Heerdegen" <michael_heerdegen@web.de>
> Cc: "65348@debbugs.gnu.org" <65348@debbugs.gnu.org>, "eliz@gnu.org" <eliz@gnu.org>, "heimeborgia@protonmail.com" <heimeborgia@protonmail.com>
> Subject: RE: [External] : Re: 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.

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

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

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.

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

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

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Christopher Dimech]

> Sent: Monday, August 21, 2023 at 12:23 PM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Juri Linkov" <juri@linkov.net>
> Cc: "Eli Zaretskii" <eliz@gnu.org>, "heimeborgia@protonmail.com" <heimeborgia@protonmail.com>, "65348@debbugs.gnu.org" <65348@debbugs.gnu.org>
> Subject: bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively
>
> > > In case you're thinking, for your "obvious" use
> > > cases, of a case where you have few completion
> > > candidates, such as just "alpha", "beta", "gamma",
> > > then let's not forget that you can already cycle
> > > among those now, as completion candidates, without
> > > having them added to the future history.  That's
> > > available since Stefan added candidate cycling,
> > > AFAIK.
> >
> > Your answers are too short.  Please elaborate
> > what do you mean by "candidate cycling" and
> > what keys do you press to cycle candidates?
>
> Sorry.  First, I'm no expert on the cycling provided
> by vanilla Emacs.  I believe Stefan introduced it.
> He can probably tell you more, and better.
>
> There are two different completion metadata entries,
> `display-sort-function' and `cycle-sort-function'.
> See (elisp) `Programmed Completion':
>
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Programmed-Completion.html
>
> (I don't see why anyone would ever want those two to
> have different values, but I don't think my ignorance
> about that is very relevant here.)
>
> Dunno whether there is some key that, by _default_,
> invokes one or the other of those functions.
>
> I use them in a two of my libraries, `sortie.el'
> and `keysee.el', to use vanilla Emacs cycling
> for cycling and display, together.
>
> With sortie.el, when you hit a key (`C-,' by
> default) the candidates in *Completions* are
> re-sorted, and so are the candidates you cycle
> through (same sort order).  So when you cycle to
> a candidate, that's also the current candidate
> in *Completions*.
>
> To turn on cycling you need to give
> `completion-cycle-threshold' a non-nil value.
> Then you can cycle among candidates using `TAB'.
>
> keysee.el uses key descriptions as candidates.
> sortie.el uses sort orders (functions) as
> candidates.  keysee.el uses sortie.el to let you
> change how its candidate key descriptions are
> sorted.
>
> In the Commentary of sortie there's a simple
> example of using the features it provides.
> Here's most of that example:
>
> (defun my-completion-with-sort-cycling ()
>   "Read and echo choice using completion with sort-order cycling."
>   (interactive)
>   (minibuffer-with-setup-hook #'sorti-bind-cycle-key
>     (let ((sorti-current-order          'order1)
>           (sorti-sort-function-chooser  'my-sort-fn-chooser)
>           (sorti-sort-orders-alist      '((order1 . "alphabetical")
>                                           (order2 . "by length")))
>           (sorti-sort-orders-ring       (let ((rng  (make-ring 4)))
>                                           (ring-insert rng 'order1)
>                                           (ring-insert rng 'order2)
>                                           rng)))
>       (message "RESULT: %S"
>                (completing-read "fff: "
>                                 (my-collection-fn
>                                  '("aa" "bb" "ab" "aaff" "c")))))))
>
> (defun my-collection-fn (candidates)
>   "Collection function that provides metadata for sorting.
> Sorting is per the current value of `my-sort-fn-chooser'."
>   (lambda (string pred action)
>     (if (eq action 'metadata)
>         (let ((order  (my-sort-fn-chooser)))
>           `(metadata ,@(and order
>                             `((display-sort-function . ,order)
>                               (cycle-sort-function   . ,order)))))
>       (complete-with-action action candidates string pred))))
>
> (defun my-sort-fn-chooser ()
>   "Return sort function for current value of `sorti-current-order'."
>   (if (eq 'order2 sorti-current-order)
>       'my-sort-by-length
>     'my-sort-alphabetically))
>
> So for example, with both sortie.el and keysee.el
> loaded, if you turn on mode `kc-mode' then
>
> * `S-TAB' shows currently available key bindings.
> * `C-,' re-sorts them in a few different ways
>   (for both *Completions* display and cycling).
>   You cycle among the available sort orders, to
>   choose one, with `completing-read'.
> * `TAB' cycles among the key bindings, to choose
>   one, with `completing-read'.
> ___
>
> As I say, I don't know how others make use of the
> vanilla cycling feature.  Maybe Emacs provides a
> key for such cycling by default, but I doubt it.
>
> I think you have to define the cycling yourself,
> by defining a function (such as `my-collection-fn'
> above) that dynamically sorts the candidates to
> produce a COLLECTION that's sorted as desired.
>
> But is it really needed - by default, i.e., in
> general - to be able to cycle among all candidates
> in COLLECTION?  Certainly some libraries, such as
> Icicles, offer that, but it's not as if it's so
> essential that vanilla Emacs should provide it by
> default, I think.  It makes sense to give coders
> ways to provide candidate cycling when they want
> it for `completing-read'.
>
> My main point was that IF any such cycling of
> COLLECTION entries is provided, it need not, and
> should NOT, be part of the history (future or not).
> Leave the history cycling to minibuffer input
> HISTORY and to DEFAULTS.  If you want cycling of
> all candidates in COLLECTION then provide that as
> a different kind of cycling (different key).

I would agree with such evaluation.  One should enter COLLECTION
and then instruct the function how to use it.

> > Then maybe this cycling could be used instead of 'M-n'.
>
> No, not in my opinion; not at all.
>
> `M-n' should be only for cycling forward in the
> history, just as `M-p' should be for cycling
> backward.  Users should know that that's what's
> being cycled, and that those things are NOT, in
> general, candidates from COLLECTION.  (Think lax
> completion.)
>
> The "feature" of unequivocally adding COLLECTION
> to the history mixes things that don't belong
> together.  It doesn't help users, IMO; and it can
> confuse them, by mixing carrots with car parts.
>
> My call is to first-and-foremost give control to
> (1) users interactively and (2) coders who call
> `completing-read'.
>
> We already have a way for any coder to add all of
> COLLECTION to the "future history": use it as, or
> include it in, the value of argument DEFAULTS.
> _End of story._
>
> That gives coders 100% control over such addition.
> It's not blindly imposed on them.  And it's easy
> to obtain when/if they want it.  Easy peasy.  They
> already have COLLECTION - just pass it also as arg
> DEFAULTS (or part of DEFAULTS).
>
> Arg DEFAULTS should, _alone_, determine/define the
> "future history".  You can do anything you want
> with it, including get the current behavior that
> gets imposed unilaterally.  But you need not live
> with that imposition.
>
> Do I want to argue this in emacs-devel?  Not really.
> I really don't have time for such things these days.
>
> But do I wish something were done to remove this
> imposition and give control back to coders & users?
> Absolutely.  If this makes sense to you, go for it.
>
> And I think it's simple to do: (1) Stop filling
> future history with COLLECTION, or at least provide
> a simple means to stop that.  (2) Point out to users
> that IF they want to for some reason (the "many" use
> cases Eli hinted at), they can simply include all of
> COLLECTION as, or in, the future history, by just
> passing it as (or as part of) the list arg DEFAULTS.
>
> What's more, they can sort it first, any way they
> like.  And they can filter it, if they don't want to
> include _all_ of COLLECTION.  The current "feature"
> is brutal - it's a one-size-fits-none, IMO.  It was
> never needed (DEFAULT suffices), and it can't be
> turned off.
>
> #2 is maybe not obvious, even though it has been
> available since Day One.  If it were really so
> useful in "many" situations then I think we would
> have seen "many" users pass COLLECTION also as
> DEFAULTS (e.g. before Emacs 23).  I seriously doubt
> we'v seen many - maybe not even any.
>
> Yet someone thought it was a great idea to impose
> that behavior always, on everyone - every call to
> `completing-read' that uses an explicit COLLECTION.
> Dunno who did that, and as Eli says, apparently it
> was done in Emacs 23.  I guess many of us just
> never noticed it.
>
> BTW, what about a COLLECTION that's not explicit,
> that's realized bit by bit with a function?  That
> doesn't work anyway for this "feature", I guess.
> You need to manifest an explicit COLLECTION, in
> order to add it to any history (history needs to
> be manifest for the call to `completing-read').
>
> (I guess if you know the candidate domain you can
> use `all-completions' with a function COLLECTION
> to get an explicit version, if you really need to
> add it to the future history.)
>
> HTH.  And BTW, thanks, Juri, for enhancing DEFAULT
> to be able to be a list (long ago).
> ___
>
> https://www.emacswiki.org/emacs/download/sortie.el
>
> https://www.emacswiki.org/emacs/download/keysee.el
>
>
>
>
>
>

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!

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

[Christopher Dimech]

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

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

[Christopher Dimech]

Eli, there needs to be some clarification.  Initially this was about
INITIAL-INPUT, its possible deprecation in the doctring, and the
COLLECTION-HISTORY debacle.

What is the situation exactly ? Is the use of nil for INITIAL-INPUT
consistent with the future plan about INITIAL-INPUT ?  Having the ability
to prefill the minibuffer with a collection entry is perfectly reasonable
expectation for people to use.

As for the COLLECTION-HISTORY thing, it is something that can be considered
in a different titled discussion, if need be.

> 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>, "65348@debbugs.gnu.org" <65348@debbugs.gnu.org>, "eliz@gnu.org" <eliz@gnu.org>, "heimeborgia@protonmail.com" <heimeborgia@protonmail.com>
> Subject: RE: 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?
>
> > > 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!
>

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Eli Zaretskii]

> From: Christopher Dimech <dimech@gmx.com>
> Cc: Michael Heerdegen <michael_heerdegen@web.de>, "65348@debbugs.gnu.org"
>  <65348@debbugs.gnu.org>, "heimeborgia@protonmail.com"
>  <heimeborgia@protonmail.com>, Drew Adams <drew.adams@oracle.com>
> Date: Mon, 21 Aug 2023 09:21:40 +0200
> 
> Eli, there needs to be some clarification.

I think the situation is clear, you (not necessarily you personally)
are just splitting hair and desperately looking for problems where
there are none.

> What is the situation exactly ? Is the use of nil for INITIAL-INPUT
> consistent with the future plan about INITIAL-INPUT ?  Having the ability
> to prefill the minibuffer with a collection entry is perfectly reasonable
> expectation for people to use.

There are no plans to remove INITIAL-INPUT, if that's what you are
asking.  We cannot possibly remove it, ever.  The argument is not
deprecated; its _use_ is "deprecated" (a.k.a. "discouraged"), that's
all.

There's no problem here.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Christopher Dimech]

> Sent: Monday, August 21, 2023 at 11:40 PM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: michael_heerdegen@web.de, 65348@debbugs.gnu.org, heimeborgia@protonmail.com, drew.adams@oracle.com
> Subject: Re: [External] :  bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively
>
> > From: Christopher Dimech <dimech@gmx.com>
> > Cc: Michael Heerdegen <michael_heerdegen@web.de>, "65348@debbugs.gnu.org"
> >  <65348@debbugs.gnu.org>, "heimeborgia@protonmail.com"
> >  <heimeborgia@protonmail.com>, Drew Adams <drew.adams@oracle.com>
> > Date: Mon, 21 Aug 2023 09:21:40 +0200
> >
> > Eli, there needs to be some clarification.
>
> I think the situation is clear, you (not necessarily you personally)
> are just splitting hair and desperately looking for problems where
> there are none.
>
> > What is the situation exactly ? Is the use of nil for INITIAL-INPUT
> > consistent with the future plan about INITIAL-INPUT ?  Having the ability
> > to prefill the minibuffer with a collection entry is perfectly reasonable
> > expectation for people to use.
>
> There are no plans to remove INITIAL-INPUT, if that's what you are
> asking.  We cannot possibly remove it, ever.  The argument is not
> deprecated; its _use_ is "deprecated" (a.k.a. "discouraged"), that's
> all.

INITIAL-INPUT is basically meant for prefilling the minibuffer with an entry.
Do not see anything to encourage or discourage.  Perhaps renaming it would be
more appropriate to describe what actually happens ?

> There's no problem here.

Then there is no problem.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Eli Zaretskii]

> From: Christopher Dimech <dimech@gmx.com>
> Cc: michael_heerdegen@web.de, 65348@debbugs.gnu.org,
>  heimeborgia@protonmail.com, drew.adams@oracle.com
> Date: Mon, 21 Aug 2023 14:07:07 +0200
> 
> > There are no plans to remove INITIAL-INPUT, if that's what you are
> > asking.  We cannot possibly remove it, ever.  The argument is not
> > deprecated; its _use_ is "deprecated" (a.k.a. "discouraged"), that's
> > all.
> 
> INITIAL-INPUT is basically meant for prefilling the minibuffer with an entry.

Yes.

> Do not see anything to encourage or discourage.

The doc string and the manual explain this.

> Perhaps renaming it would be more appropriate to describe what
> actually happens ?

I see no reason to rename, as the current name describes the purpose
quite well.

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sent with Proton Mail secure email.

------- Original Message -------
On Tuesday, August 22nd, 2023 at 12:25 AM, Eli Zaretskii <eliz@gnu.org> wrote:


> > From: Christopher Dimech dimech@gmx.com
> > Cc: michael_heerdegen@web.de, 65348@debbugs.gnu.org,
> > heimeborgia@protonmail.com, drew.adams@oracle.com
> > Date: Mon, 21 Aug 2023 14:07:07 +0200
> > 
> > > There are no plans to remove INITIAL-INPUT, if that's what you are
> > > asking. We cannot possibly remove it, ever. The argument is not
> > > deprecated; its use is "deprecated" (a.k.a. "discouraged"), that's
> > > all.
> > 
> > INITIAL-INPUT is basically meant for prefilling the minibuffer with an entry.
> 
> 
> Yes.
> 
> > Do not see anything to encourage or discourage.
> 
> 
> The doc string and the manual explain this.
> 
> > Perhaps renaming it would be more appropriate to describe what
> > actually happens ?
> 
> 
> I see no reason to rename, as the current name describes the purpose
> quite well.

Consequently, its _use_ should not be discouraged.  It is for the person 
calling the function to decide whether it is appropriate for their package.

Is prefilling the minibuffer wrong as matter of principle ?  Or just that 
on occasions it is not useful ?

bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Drew Adams]

> There are no plans to remove INITIAL-INPUT, if that's what you are
> asking.  We cannot possibly remove it, ever.  The argument is not
> deprecated; its _use_ is "deprecated" (a.k.a. "discouraged"), that's
> all.
> 
> There's no problem here.

So no change.  Good to hear!  (Not as good as
removing the stylistic stigma from INITIAL, but
good enough).  Thx.