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

[Drew Adams]

    > I don't care about that, because I don't use
    > `minibuffer-completion-help'.

    That's OK.  All I'm saying is that this is the right place to
    do removal of duplicates and that if there are duplicates
    which are not truly identical, then the UI has to somehow
    make the difference visible to the user, so the
    code that displays the list should have the necessary info to
    know whether to remove the duplicates or not.  I.e. it can
    always be done in minibuffer-completion-help or in the
    equivalent function in your code, rather than earlier in the
    completion table.

I guess I'm not making myself clear, probably on more than one point. I
think I made #1, 2, and 3 clear. #4, 5, 6, and 7 are what are important to
me.

1. The duplicates are not identical, if you consider the whole key-value
pair as an entry, as I do in some situations (but as Emacs does not).

2. The duplicates *are* truly identical, from the perspective of completion,
which cares only about the key of alist TABLE key-value pairs. AFIAK, both
completing-read and read-file-name completely ignore the values of such
pairs. They accept an alist, but they use only the cars.

3. If Emacs removes duplicates in sense #2 at the point of
`minibuffer-completion-help', then I don't care, because I don't use that
function. I don't think it is proper for `minibuffer-completion-help' to do
that, but I can't complain about it, because I don't use it.

4. Other people who might like to take advantage of a) duplicate keys with
different values or b) the original candidate order might not want to do
everything that I do in my code. They might want to simply use
`minibuffer-completion-help' to display the candidates. They will not be
able to do that, because `minibuffer-completion-help' eagerly and blindly
strips duplicates and sorts the candidates it displays.

5. *Unlike* `minibuffer-completion-help', the function that calls
completing-read or read-file-name *knows* whether it wants duplicates
displayed in *Completions* or not. That function should have the
responsibility of removing duplicates, if it deems that appropriate.
Likewise sort. It should have the possibility of not removing duplicates or
not sorting, and have that reflected in the *Completions* list. This seems
logical to me - `minibuffer-completion-help' should not be deciding what the
caller needs.

6. Yes, in Emacs it might seem silly now for `locate-file-completion' to
remove duplicates, because they are always removed anyway by
`minibuffer-completion-help'. I'm suggesting to remove that recent change to
`minibuffer-completion-help', and let the caller send just what it needs to
completing-read. Having the caller strip and sort is cleaner, in the sense
that it is lazier, and it leaves open the possibility that Emacs too, or
other users, might someday make some use of the values in key-value pairs.

7. Regardless of whether you are convinced that, even for Emacs itself, the
proper place for duplicate removal is at the point of call, this makes a
difference to me, because, unlike `minibuffer-completion-help', I don't
assume that *all* functions calling completing-read want to strip dups and
sort candidates. In my code, it is the function that calls completing-read
that strips and sorts, if appropriate.

I only really hope to persuade you about #7 (as well as to please continue
to not strip and sort in all-completions and display-completion list). I
probably can't convince you that Emacs or other users might want to do
something like I do, but perhaps I can convince you that something like
stripping and sorting should be done on an on-demand basis, remaining
agnostic on the question as long as possible, and letting the code at point
of call decide on the behavior.

Laziness (vs eager, systematic stripping & sorting) keeps options open.
Callers such as `locate-file-completion' know what they need;
`minibuffer-completion-help' doesn't know what each caller might need (today
for Drew, tomorrow for *).

Thx - Drew