> It's true that the completion candidates themselves are just
> strings, but the completion alist passed to completing-read
> or read-file-name can have key-value pairs, and those values
> can be exploited. I track which candidate is chosen, so I
> can tell which of any duplicate candidate strings is picked.
> Then I can use the associated value.
So the duplicate removal can still be in
display-completion-list because the
"duplicates" aren't quite duplicates.
If display-completion-list removes duplicate candidate strings, then I will
be very upset. The argument to display-completion-list is not the alist
TABLE argument to completing-read, so it will not be finding, say, that
("foo" 2378) is different from ("foo" 945). Those are the key-value pairs I
use, but display-completion-list never sees them.
The argument to display-completion-list is a list of candidate strings or
symbols (or a list of pairs of strings) to be displayed. I don't know what
functions pass a list of string pairs to display-completion-list, but I'm
pretty sure that having display-completion-list remove duplicates would not
work for me.
As I said, however, the duplicate removal is in `minibuffer-completion-help'
today (before the call to display_completion_list_1), and I don't care about
that, because I don't use `minibuffer-completion-help'.
Regardless of whether `minibuffer-completion-help' removes duplicates and
sorts, I would appreciate it if all callers of completing-read do so, when
they expect a sorted display of candidates with no duplicates. If they
don't, that's a minor inconvenience for me (my code will display the
duplicates). If you change all-completions or display-completion-list so
they remove duplicates, that's a major problem for me.
_______________________________________________
emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
