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

From: Heime <[email-masked]>
Date: Fri, 18 Aug 2023 19:12:49 +0000

------- Original Message -------
On Saturday, August 19th, 2023 at 5:33 AM, Drew Adams <[email-masked]> 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.