Many repeated candidates with `load-library`.

[okamsn]

For example, I see 157 occurrences of ./ as a candidate. This doesn't happen with Icompete or default completion.

The problem is found here:

(completing-read "Load library: "
                 (apply-partially 'locate-file-completion-table
                                  load-path
                                  (get-load-suffixes)))

[clemera]

Thanks, this seems to be a problem with the completion table which returns those duplicates:

(funcall
       (apply-partially 'locate-file-completion-table
                        load-path
                        (get-load-suffixes))
       "" nil t)

Apparently default completion does filter duplicates so Selectrum should probably do so as well but this will also slow down initialization a bit more.

[raxod502]

We don't need to filter duplicates in selectrum-read, only selectrum-completing-read, if it's a problem of interface conformance. That shouldn't introduce a performance hit that is ~any worse~ too much worse than the default completing-read mechanism.

[raxod502]

Also, what is the deal with those ./ entries anyway? I was always confused by them, it's not like they're libraries. Presumably there's some reason they appear...?

[clemera]

help--symbol-completion-table can get pretty big and already gets slowed down by sorting. Maybe we could leave duplicates for now and adjust only for locate-file-completion-table for now? If there come up more examples of completion tables with duplicates we could still decide to remove them by default.

what is the deal with those ./ entries anyway?

I wonder, too. No idea :man_shrugging:

[raxod502]

I suppose that's a fine solution. We could have a user option that is an alist of completion table symbols that gives special information about each one. For example, one of the properties could be whether to remove duplicates. If later problems come up with specific completion tables in ways that are difficult to work around generally, we could add them as additional properties in the alist. (Did we already run into a problem like this earlier?)

[okamsn]

For the case of load-library, this problem seems to be fixed.

I'm unsure about closing the issue because of the discussion.

[clemera]

For the case of load-library, this problem seems to be fixed.

Why do you think so? For me the behaviour hasn't changed I still get the duplicates.

[clemera]

The problem also exists for locate-library and finder-commentary which use the same completion table.

[okamsn]

For the case of load-library, this problem seems to be fixed.

Why do you think so? For me the behaviour hasn't changed I still get the duplicates.

The problem also exists for locate-library and finder-commentary which use the same completion table.

I no longer see the many duplicate ./ in load-library or locate-library. There are still some duplicate libraries listed, but those correspond to more than one version available (e.g., Org).

I still see the many ./ in finder-commentary, yes. finder-commentary seems to include some folders, such as org/, when running it from my home directory.

[clemera]

Strange that it is fixed for you, have you switched Emacs versions recently? I have proposed a fix in #156.

[okamsn]

Strange that it is fixed for you, have you switched Emacs versions recently? I have proposed a fix in #156.

Yes. I am now using Emacs 28, and I reported this with Emacs 27, I think.

[clemera]

Thanks, then they probably fixed it for Emacs 28.