A community for the timeless and infinitely powerful editor. Want to see what Emacs is capable of?!
As long as the completions have the same annotation (the text in green) and same kind (the icon on the left), they are deduplicated.
Looks like perhaps lsp-mode generates annotations that are more useful for your scenario than the ones that eglot does. If that is the case (and not, maybe, that you have configured lsp-mode/eglot to use different language servers), I suggest filing an issue. This shouldn't take too much time to change.
/u/hvis Would you consider changing this, since this way of deduplication in the frontend is quite inefficient? Given that the default completion UI demands that candidates are unique with respect to equal and even deletes equal duplicates, the backend should better produce unique candidates.
Deduplicating in the backend is not difficult, all that is needed is adding a suffix like (1), (2), (3), ... In fact, this is what I am doing in my Consult package, which also is a backend and provides completion tables. For example for the consult-line command I was facing the same issue, that candidates must be unique with respect to equal and not to eq.
cc /u/JDRiverRun
Iβd also worry that an eq test is a bit fragile, and could go mysteriously wrong if any step in the chain decided down the road to copy or duplicate the string.
It is not only fragile, it is also wrong, since the default completion UI even deletes duplicate candidates.
Something like that would be generally easy to see very soon (completion popup without both icons and annotations). This approach has worked for years for both Emacs's default UI and company-mode, so it's hard to call it fragile.
I suppose it might have been a cause for investigation for some backend authors at some point, but backends would generally avoid internal copying anyway, for performance reasons if nothing else.
Actually, I forgot how this works in most cases X-D.
And it happens through text properties, which backends add to their completion strings. Then the annotation and kind operations look them up.
Makes sense. I thought in the past the default completion system stripped out text properties? But I dimly recall that situation changed recently (v29?).
Would you consider changing this, since this way of deduplication in the frontend is quite inefficient?
I simply consider it part of the requirements (see the other message). And there has been some effort made to ensure that the annotation/kind functions are only called when equal strings are encountered.
Indeed, when the list is long deduplication does show up on the graph, but the impact also depends on the shape of the data, and there probably are some untapped code optimizations still.
Deduplicating in the backend is not difficult, all that is needed is adding a suffix like (1), (2), (3), ...
I'm not sure this is very easy (e.g. for LSP clients), and in general it would require a scan across all completions of comparable complexity. Also, showing method overloads with suffixes like 1/2/3 would look rather odd, I think.
I don't know how that would even work. How do you differentiate between the funcions? Do you do fs.watch, vue.watch and so on? If so, maybe try doing fs.? Shouldn't it popup then?
This implies that I need to know each module and the exact path to it. I would like to be able to see where potential candidates are placed.
