From: Drew Adams <drew.adams@oracle.com>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>,
Oleh Krehel <ohwoeowho@gmail.com>
Cc: 20365@debbugs.gnu.org
Subject: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1
Date: Sat, 18 Apr 2015 16:40:03 -0700 (PDT) [thread overview]
Message-ID: <2c99be72-92a2-4e33-84fc-5ce168624af2@default> (raw)
In-Reply-To: <jwvr3rhs5pu.fsf-monnier+emacsbugs@gnu.org>
> Just a first comment: it's not considered incorrect for
> `all-completions' to return a list with duplicate entries in it.
> More specifically, it's considered the completion UI's job to remove
> those duplicates.
Yes, absolutely.
> > (setq x (all-completions "(" 'Info-read-node-name-1))
> > x will contain many duplicates for each node, like "org" "org"
> > "org" "org" "org.info.gz" "org" "org.info.gz" "org" "org.info.gz".
>
> Maybe the way these entries are generated could be reviewed to try
> and reduce the number of duplicates. And we could call `delete-dups' on
> the result: while a completion-table shouldn't need to go out of its way
> to reduce the number of duplicates (since the UI is supposed to handle
> it anyway), it's probably good to avoid having such expected large
> number of duplicates, indeed.
Just to be sure -
I hope you mean to do this only in `Info-read-node-name-1' or
in the code that calls `completing-read' (or in a "completion UI").
I hope you don't mean to do any of that in `all-completions'.
I'm guessing that this is what you mean.
If my guess is correct, then you need not read any further,
and thanks for confirming the guess.
---
In case not, let me disagree that such things should be done in
`all-completions' and similar functions or in `completing-read'.
They should not delete duplicates.
In my context, for instance, the completion candidates are often
alist elements where the cdrs matter. Or they are strings that
are `string=' but have different properties. The cdrs or the
string properties matter to the code that calls `all-completions'
or `completing-read'. The calling code reconstructs the alist
element from the chosen candidate(s) (it provides access to the
associated cdr information).
It is important in such contexts to allow "duplicates", as
defined from the point of view of comparing only the cars with
`string=' (which is what `all-completions' does). Just
because two completion candidate strings are equal does not
mean that the alist elements of which they are the cars are
equal.
It should be entirely up to the caller to delete duplicates.
It is trivial for it to do so, and logical that this be the
place where that is done. Only the caller (or the "completion
UI") knows whether duplicates make sense in the current context.
`all-completions' & compagnie are building blocks (and coded
in C, no less, so not tweakable in Lisp). It is not their
job to either (a) filter out duplicates or (b) try not to
produce duplicates. (a) is the job of their callers, which
are the consumers of the candidates. (b) is the job of the
COLLECTION function or other producer of the candidates.
So please try to tackle any problem of duplicates in this
particular use case by fiddling with `Info-read-node-name-1',
and not by introducing a change in `all-completions' etc.
next prev parent reply other threads:[~2015-04-18 23:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-18 16:11 bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 Oleh Krehel
2015-04-18 17:41 ` Stefan Monnier
2015-04-18 17:49 ` Oleh Krehel
2015-04-19 2:04 ` Stefan Monnier
2015-04-19 11:53 ` Oleh Krehel
2015-04-19 14:43 ` Drew Adams
2015-04-19 16:44 ` Dmitry Gutov
2015-04-19 17:00 ` Oleh Krehel
2015-04-19 17:12 ` Dmitry Gutov
2015-04-20 2:29 ` Stefan Monnier
2015-04-20 8:38 ` Oleh Krehel
2015-04-20 12:30 ` Oleh Krehel
2022-04-17 10:51 ` Lars Ingebrigtsen
2015-04-20 14:38 ` Stefan Monnier
2015-04-20 14:52 ` Oleh Krehel
2015-04-20 19:14 ` Stefan Monnier
2015-04-18 23:40 ` Drew Adams [this message]
2015-04-19 1:50 ` Stefan Monnier
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=2c99be72-92a2-4e33-84fc-5ce168624af2@default \
--to=drew.adams@oracle.com \
--cc=20365@debbugs.gnu.org \
--cc=monnier@IRO.UMontreal.CA \
--cc=ohwoeowho@gmail.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).