From: Drew Adams <drew.adams@oracle.com>
To: Heime <heimeborgia@protonmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
"65348@debbugs.gnu.org" <65348@debbugs.gnu.org>
Subject: bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively
Date: Fri, 18 Aug 2023 21:03:30 +0000 [thread overview]
Message-ID: <SJ0PR10MB5488DEB7D60756DBDEF965C5F31BA@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <AaDc9_bNKawd-22E-KkyaSBhiOpbBEmjKyX8lqfdGvfKQUznsqMaVhPvEgMiQkggNIR6S7kvbOMVZiA5VYXm4hIE9W5O1BhpsLA63Hb0Z6Q=@protonmail.com>
> > 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
next prev parent reply other threads:[~2023-08-18 21:03 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-17 0:47 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
2023-08-17 5:49 ` Eli Zaretskii
2023-08-17 6:05 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-17 7:20 ` Eli Zaretskii
2023-08-17 10:27 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-17 10:45 ` Eli Zaretskii
2023-08-18 0:35 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 1:47 ` Drew Adams
2023-08-18 3:49 ` Eli Zaretskii
2023-08-18 5:13 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 5:36 ` Eli Zaretskii
2023-08-18 5:56 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 6:32 ` Eli Zaretskii
2023-08-18 8:40 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 12:14 ` Eli Zaretskii
2023-08-18 12:27 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 12:30 ` Eli Zaretskii
2023-08-18 12:55 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 13:27 ` Eli Zaretskii
2023-08-18 13:36 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 15:23 ` Drew Adams
2023-08-18 15:16 ` Drew Adams
2023-08-18 15:43 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 17:33 ` Drew Adams
2023-08-18 19:12 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 21:03 ` Drew Adams [this message]
2023-08-19 1:55 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-19 2:34 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-19 4:14 ` Drew Adams
2023-08-19 4:22 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-19 4:46 ` Drew Adams
2023-08-19 5:05 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-19 6:34 ` Eli Zaretskii
2023-08-19 16:20 ` Drew Adams
2023-08-19 19:19 ` Eli Zaretskii
2023-08-19 20:56 ` Drew Adams
2023-08-20 16:39 ` Juri Linkov
2023-08-21 0:23 ` Drew Adams
2023-08-21 4:34 ` Christopher Dimech
2023-08-20 5:42 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-20 6:12 ` Michael Heerdegen
2023-08-20 6:23 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-20 6:34 ` Christopher Dimech
2023-08-21 0:25 ` Drew Adams
2023-08-21 4:26 ` bug#65348: RE: [External] : " Christopher Dimech
2023-08-21 5:23 ` Drew Adams
2023-08-21 6:29 ` Christopher Dimech
2023-08-21 7:21 ` bug#65348: " Christopher Dimech
2023-08-21 11:40 ` Eli Zaretskii
2023-08-21 12:07 ` Christopher Dimech
2023-08-21 12:25 ` Eli Zaretskii
2023-08-21 13:27 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-21 16:08 ` Drew Adams
2023-08-18 19:45 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 21:07 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SJ0PR10MB5488DEB7D60756DBDEF965C5F31BA@SJ0PR10MB5488.namprd10.prod.outlook.com \
--to=drew.adams@oracle.com \
--cc=65348@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=heimeborgia@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).