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