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

[Stefan Monnier]

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

I.e. they are not identical.  Emacs does support this notion at various
places (the key-value pairs in alists and things like that), but indeed it
doesn't actually use it.

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

I.e. even though they are not identical, the current code in Emacs doesn't
pay attention to the difference in the value slot and thus mistakenly
conflates such similar-but-not-identical entries.

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

[ I'll ignore ordering here because I believe it's a separate issue ] So
you're saying that minibuffer-completion-help is incorrect in that it should
not remove such non-identical duplicates.  I think this makes sense,
although only if the value slot is actually used somewhere.  I.e. only if it
gets changed such that the value slot gets propagated to
display-completion-list.

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

Depends which kind of duplicate (identical or not), right?  Can you give
an example?

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

minibuffer-completion-help doesn't work in a vaccum: it uses data provided
by the caller.  So we can easily make it possible for the caller to tell
minibuffer-completion-help whether to remove duplicates or not, and whether
to sort or not.

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

Removing duplicates and sorting is the right thing to do in 99% of the
cases, so it makes a lot of sense to do it once and for all, rather than
dump that responsibility onto every single caller.
If you want a way to turn off that sorting and duplicate removal, that's
fine, but doing it by default is TRT.

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

(with-provocative-mode
 So you suggest to change the way Emacs works rather than change the way your
 code works?)

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

There has never been any intention to strip duplicates and/or sort in
all-completions or in display-completion-list, AFAICT.

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

If the strip&sort is done by the caller (as you suggest) before passing the
resulting list to minibuffer-completion-help, then there's no way for
someone to use his own version of minibuffer-completion-help which doesn't
sort and doesn't strip.
I.e. doing it in minibuffer-completion-help (controlled by an option that
can be set by the caller) is exactly what you ask for: remaining agnostic on
the question as long as possible.


        Stefan