RE: should locate-file-completion filter out "./" and "../"?

[Drew Adams]

    > 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.