GNU bug report logs - #65348
INITIAL-INPUT in completing-read repeats same entry twice consecutively

Previous Next

Full log

View this message in rfc822 format

From: Heime <heimeborgia <at> protonmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, "65348 <at> debbugs.gnu.org" <65348 <at> debbugs.gnu.org>
Subject: bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively
Date: Sat, 19 Aug 2023 01:55:14 +0000

------- Original Message -------
On Saturday, August 19th, 2023 at 9:03 AM, Drew Adams <drew.adams <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.